Le numérique a longtemps cherché la pérennité. Aujourd’hui, la rapidité d’évolution des modèles d’IA rend toute construction à long terme obsolète avant même sa livraison. Bienvenue dans l’ère du « Just-in-Time Software ».
Le risque lors des profondes mutations, c’est de ne pas les voir. Ou pas entièrement. Ou trop tard. Ça peut paraître inconcevable (ne serions-nous pas un peu trop sûrs de nous ?). Et pourtant, l’éléphant au milieu de la place qu’est l’IA et que nous côtoyons au quotidien va aussi toucher ce que nous croyions acquis et immuable.
Il y a de fortes chances que si vous me lisez, vous baigniez dans le web (fin des années 90) et dans l’informatique personnelle (années 80) depuis votre enfance. Ça a toujours été là, ça fait partie du décor. Je crois que ce décor va lui aussi être transformé de fond en comble. Prenons l’exemple du développement et des logiciels.
Du beau code au code jetable
Jusqu’à très récemment, le code réalisé par des développeurs était prévu pour durer. Il était pensé pour être efficace, adaptable, résilient, élégant. Ça faisait partie des bonnes pratiques. Les revues de code et la refactorisation permettaient de produire la qualité (élevée) souhaitée et de la maintenir.
Il y a toujours eu du code « vite fait » pour des usages sans enjeu. Et il y a toujours eu du code mal conçu qui passait malgré tout en prod.
Depuis quelques années, avec l’IA, je vois apparaître le code jetable (ou si on veut être poli, du code « de transition »). L’idée, c’est que le code n’est plus un investissement mais du consommable. Il faut produire et livrer vite.
Que le code soit propre ou bien pensé n’est plus aussi important qu’avant et débugger passe pour un usage du monde d’avant. S’il y a besoin de changer quelque chose ou de réparer un bug, on demande à l’IA de refaire. Pourquoi s’embêter ? La production de code ne coûte plus rien. Elle ne vaut donc plus rien. Ainsi on jette et on recommence.
Le « beau code » bien documenté est un luxe que certains sur le marché ne paient plus.
Le piège ? L’idée de « code jetable » nécessite paradoxalement une architecture modulaire parfaite (micro-services), sinon tout s’effondre au premier bug. Alors, c’est vrai, en pratique ça marchouille. Un temps seulement et pour certains usages (un POC typiquement). Les juniors sont contents de mettre le leçon aux dev seniors mais quand ça coince vraiment ou qu’il faut scaler ou qu’il faut rendre des comptes, on revient – pour le moment encore – aux anciennes méthodes.
Est-on prêt à accepter l’opacité totale de ce code jetable généré de façon industrielle et sans validation solide ? Et comment gérer la conformité (RGPD, audits) avec du jetable ?
Des bases de données forteresses aux données fluides
Dans ma formation de développeur, la modélisation était très importante. On utilisait des modèles costauds (Merise – comme pour les centrales nucléaires, ou UML – pour gérer des « objets »).
Bien organisées, validées, formatées et filtrées, les données étaient stockées dans des bases de données prévues pour répondre à quelques requêtes bien construites (en SQL). Cette rigidité apportait la rigueur nécessaire aux besoins de l’informatique d’alors.
À l’époque de l’IA, ça ne suffit plus. Comment gérer des données partielles ? Comment considérer de nouvelles données non imaginées lors de la conception mais désormais importantes tout de suite ? Comment lier et faire parler des données hétérogènes de façon ponctuelle ou pérenne ?
Si une IA décide de lancer 10000 requêtes d’une ligne en 1 seconde et de ne plus interroger la base pendant une semaine, pourquoi subir les limitations historiques (des délais trop long) et en plus payer pour ne pas se servir de la base le reste du temps (coûts de licence et d’infrastructure) ?
Autre préocuppation : encore plus qu’avant, les données doivent être un actif circulant. La technique ne doit pas bloquer l’interopérabilité. Les données doivent pouvoir être extraites, modifiées, ajoutées facilement. Peu importe qui (ou quoi) le demande et comment est faite la demande. Évidemment, sans concession aucune sur la sécurité ou la traçabilité.
Concrètement, il faudrait que les données soient en ligne en format ouvert dans un seul dataset, interrogeables à la volée (paiement uniquement à la réalisation d’une tâche) et via différents outils/technos, avec un mécanisme de branches (git) et avec une traçabilité complète.
Cette interopérabilité totale impose des changements de conception, de logiciels, d’infrastructure et d’accès… Rien que ça. Sinon, nos anciennes bases de données vont devenir les geoliers de nos données, accumuler de la dette technique et créer du passif financier.
Reste alors à répondre à la question qui fâche : comment garantir la souveraineté et la sécurité dans un système « ouvert » par défaut ? Comment concilier la précision et un traitement d’excellence avec des données non structurées ?
De l’UX au design pour les algorithmes : De user first à robots first
Avant, il y avait des logiciels, des sites web et des applications mobiles conçus pour les humains. Les données étaient accessibles via des écrans. Les traitements étaient réalisés en arrière-plan et récoltés par l’homme.
Aujourd’hui, l’économie bascule de l’attention à l’intention et les agents n’ont pas besoin de logiciels de workflows mais de représentations structurées de la connaissance de l’entreprise.
L’interface visuelle (GUI) devient secondaire face à l’interface de données (choisis ton camp : API, Headless, MCP, A2A, données structurées…). Conséquence, on ne designe plus les logiciels pour l’œil humain, mais pour la capacité d’un agent IA à extraire l’intention. Ce que ça veut dire, c’est qu’il n’y a plus besoin d’interface graphique. Obsolètes donc les nouveaux outils qui font leur petit effet waouh parce qu’ils savent bouger la souris, pointer, cliquer, remplir des champs et passer de page en page.
L’UX ne disparaît pas, elle se déplace vers la supervision.
Ce n’est pas tout. Ce que veulent les robots, ce sont des points de connexion pour échanger de machine à machine.
Si l’on pousse la logique à fond, la notion même d’API doit être étendue et les possibilités des échanges entre machines doivent être personnalisables à la volée. Avant (et c’est toujours le cas), les APIs proposaient des points de terminaisons finis. Force à chacun de faire avec. Et si les portes d’entrées sur les APIs étaient dynamiques ?
Exemple : un robot interroge un service pour connaître ses possibilités. Le service répond avec les commandes et données de base. Le robot demande à avoir accès à d’autres données ou sous une autre forme. Le service génère à la volée les bonnes méthodes pour que le robot puisse uniquement récupérer ce dont il a besoin. Une fois l’échange réalisé, la personnalisation est refermée. Elle pourra être réouverte si besoin plus tard.
Dans ce contexte, les APIs deviennent extensibles à la volée. Toutes les données sont accessibles et uniquement ce qui est utile pour le besoin du moment est transmis. C’est comme avant sauf que les méthodes peuvent être produites sur-mesure à chaque appel.
Ce n’est pas seulement utile d’avoir des interfaces machines ouvertes, c’est indispensable dans un monde où ce sont les robots qui interrogent de façon autonome d’autres robots. Si un robot sait que vous ne proposez pas ce qu’il souhaite, vous n’existez pas/plus. Si à l’inverse, vous êtes capable de jouer son jeu et de lui livrer ce qu’il souhaite, vous faitse partie de ses solutions et vous entrez dans son univers des possibles.
Ça semble futuriste ? Donnons-nous quelques mois…
Reste deux questions fondamentales :
- Comment séduire des humains (qui vont encore décider et payer pendant quelques années) et en même temps des robots (qui vont agir) alors qu’ils n’ont pas les mêmes attentes, les mêmes logiques ni les mêmes biais de décision ?
- Comment sécuriser une API qui « génère de nouvelles méthodes » à la demande ? C’est une porte ouverte monumentale aux injections et à l’exfiltration de données non autorisées.
SaaS : la fin de la rente au siège
Pour les éditeurs, ce qui a été génial pendant 20 ans avec les SAAS, c’est de facturer l’accès sous forme d’abonnement par utilisateur.
Cette approche est devenue complètement illogique dans un monde d’automatisation ou l’utilisateur humain n’est plus l’utilisateur principal. L’utilisateur principal devient le robot.
Ce qui est nécessaire aujourd’hui est de pouvoir facturer à la complétion d’une tâche (une question au support résolue, un devis généré, une facture émise, un paiement collecté en compta). Chaque tâche coûte quelques centimes et seules les actions réellement réalisées sont facturées. À la fin du mois, l’utilisateur ou l’entreprise ne paie que pour les résultats réellement obtenus.
Ça ne va pas plaire à une multitude d’éditeurs qui appréciaient la prévisibilité des revenus. Ça ne va pas plaire non plus à tous les services qui ne faisaient que rendre plus belles ou plus abordables les données (ils n’ont plus de raison d’être). Dans un monde où les robots échangent avec des robots, ceux qui ont les données les plus utiles, les plus riches sémantiquement, les plus rapides, les moins chères et les plus ouvertes sont recherchés. Pas ceux qui ont de beaux écrans ni ceux qui mettent en forme de la donnée.
Pour les clients, la promesse est séduisante : celle de ne payer qu’à l’usage. À condition de ne demander que ce qui est vraiment nécessaire. Car, malgré tout, les entreprises adorent les abonnements SaaS justement pour leur prévisibilité budgétaire.
Le SAAS se transforme en AGAAS (AGent As A Service). C’est la suite logique après IAAS et PAAS. Quand aura réellement lieu la bascule ?
Et avec tout ça, on fait quoi ?
Dans tout ce que je viens d’écrire, il y a certainement à trier. Et des horizons de temps qui ne sont pas tous les mêmes. Et une réalité bien différente entre les PME, les startups et les plus grosses structures. Mais, il faut embrasser les technos et les attentes qui surgissent maintenant. L’agilité a déjà muté, il faut suivre. Et trouver les bonnes réponses à ces nouveaux défis.
Gardien de la donnée, dresseur de bots, data-mixeur, grand ordonnancier des flux… Pour les professionnels du numérique mais également pour les utilisateurs, au-delà de la révolution du métier, il y a l’enjeu de la confiance. Car l’autonomie qu’on voudra bien donner à ces nouveaux outils dépendra directement de la confiance qu’on leur accordera.
Les grands bouleversements liés à l’IA ne font que commencer.