Photo de Karola G : https://www.pexels.com/it-it/foto/6229/
Il y a quelques nuits, j’ai lu un article. Il s’intitule The Death of Software 2.0 et utilise une métaphore qui m’est restée en tête : il compare le logiciel du futur aux hiérarchies de mémoire des ordinateurs. La mémoire rapide et éphémère, ce qu’on appelle DRAM, serait l’IA qui traite de manière non déterministe. La mémoire persistante, la NAND, serait la donnée structurée, les API, ce qu’on appelle single source of truth. La conclusion de l’auteur est brutale : le logiciel orienté interface utilisateur devient obsolète. Ce qui aura de la valeur, ce sont les données et les API par lesquelles les agents IA accèdent aux systèmes.
Quelque chose a fait clic dans ma tête à la lecture. Pas parce que c’était une théorie séduisante. Parce que cela décrivait exactement ce que je commence à faire dans mon travail, ce que je sens nécessaire de faire, même si une partie de moi résiste encore.
J’ai passé quinze ans à construire du logiciel selon une logique de valeur simple : d’abord l’interface, puis l’API. Du point de vue du client, l’UI était le produit, l’API un complément, une rallonge pour les intégrateurs, quelque chose à documenter quand il restait du temps. Ce modèle marchait parce que le logiciel devait être utilisé par des personnes. Ce n’est plus le cas, ou en tout cas, plus seulement.
Les agents ne cliquent pas
Claude, ChatGPT, Gemini, les agents IA, les outils agentic en général n’utilisent pas le logiciel comme un humain l’utilise. Ils ne cliquent pas. Ils ne suivent pas des flux d’UX. Ils ne se perdent pas dans les dix-sept cas limites du formulaire de checkout sur lesquels j’ai passé des semaines. Ils ont besoin de trois choses : des données structurées et accessibles via des API bien conçues, un contexte persistant qu’ils peuvent comprendre dans une conversation, des actions déterministes et répétables qu’ils peuvent orchestrer sans erreur. Si le produit que tu construis n’est pas pensé autour de ces trois piliers, tu le construis pour 2015.
Et là, je dois être honnête avec moi-même. Pendant des années, j’ai mis l’âme dans les interfaces. J’ai débattu pendant des heures de la bonne couleur d’un bouton, de l’organisation d’un menu, de la microinteraction qui rendrait l’expérience plus fluide. Ce n’était pas du temps perdu, loin de là. Mais je me demande si je ne bâtissais pas des cathédrales sur des fondations qui commençaient déjà à trembler.
MCP comme pont
Le Model Context Protocol est le standard publié par Anthropic en novembre 2024. OpenAI et Google l’ont adopté immédiatement. C’est le pont standardisé entre une IA et les systèmes d’entreprise. Jusqu’ici, chaque intégration IA était un projet sur mesure : raw API calls dans l’app, pipelines RAG fragiles, tool calling bespoke, aucune réutilisabilité, aucune gouvernance. Avec MCP, le paradigme change. Vous exposez votre système comme MCP server. L’IA le consomme comme client standardisé. Vous l’authentifiez une fois. Vous le gouvernez une fois. Vous le supervisez une fois.
Ce n’est pas peu. C’est l’équivalent de ce que HTTP a fait pour standardiser la communication sur le web dans les années 1990. Et comme HTTP, cela changera tout sans que la plupart des gens s’en aperçoivent.
Le flux réécrit
J’essaie d’imaginer ce que cela signifierait concrètement pour les clients avec qui je travaille.
Aujourd’hui, le flux est celui-ci : le client accède à l’UI, clique pour huit ou dix actions différentes, exporte les données en CSV, les colle dans une autre app, obtient le résultat. Un processus qui marche, qu’on a optimisé au fil des années, que les clients connaissent. Mais aussi un processus qui demande du temps, de l’attention, une compétence spécifique sur le fonctionnement de ce logiciel particulier.
Le flux de demain pourrait être : le client parle à Claude/ChatGPT/Gemini/whatever et dit « traite ces données et donne-moi le rapport ». Claude se connecte directement au système via MCP, lit les données, les traite, écrit le résultat dans la bonne table. Tout en dix secondes, aucun clic. Ce n’est pas l’IA qui connaît le logiciel. C’est le logiciel qui devient consommable par l’IA. Avec des outils que tout le monde utilise déjà au quotidien.
J’écris ces mots et je sens une résistance intérieure. Construire des interfaces a été mon métier pendant des années. Il y a quelque chose d’humain à dessiner une expérience, à penser à la façon dont une personne interagira avec ce que tu as créé. Il y a aussi, je dois l’admettre, une forme de contrôle. Quand tu conçois une interface, c’est toi qui décides du flux. Tu guides l’utilisateur. Tu choisis ce qu’il peut faire et pas, dans quel ordre, avec quelles contraintes. Ouvrir tout cela à un agent IA, c’est céder ce contrôle. C’est faire confiance au système pour faire la bonne chose, même quand tu ne peux pas prévoir exactement ce que l’utilisateur demandera.
Mais c’est peut-être justement le point. Peut-être que ce contrôle a toujours été une illusion, une façon de gérer la complexité en réduisant les options plutôt que de l’affronter.
Le manque de gouvernance
Les chiffres sont clairs. Plus de 80 % des équipes de développement suivent déjà une méthodologie API-first. On estime un milliard sept cents millions d’API actives en 2030, une augmentation de 300 % par rapport au baseline actuel. Adopter l’API-first par rapport aux approches traditionnelles fait baisser de 37 % les coûts d’intégration. Mais ce qui m’a le plus frappé : Gartner estime que plus de 40 % des projets avec agents IA seront annulés d’ici 2027 s’ils n’ont pas de gouvernance solide.
Voici le point où tout se complique, où la vision technologique se heurte à la réalité opérationnelle. MCP a aujourd’hui des manques importants. Pas de standard d’authentification : chaque implémentation est différente. Le sandboxing est faible : si un agent prend le contrôle, où l’arrêtes-tu ? Il y a des risques de prompt injection : comment garantis-tu que l’IA ne soit pas manipulée pour faire des actions non voulues ? Et il y a des trous d’audit : comment traces-tu qui a fait quoi et quand ?
La Commission européenne et les banques centrales européennes poussent déjà vers des API transparentes, contrôlables, auditables. Ce n’est pas qu’un choix technique. C’est un choix de survie réglementaire. Et là s’ouvre un terrain que je connais bien, celui de l’équilibre entre innovation et compliance, entre ce que tu pourrais faire et ce que tu devrais faire.
Je me retrouve souvent à réfléchir à cet équilibre. D’un côté, la pression d’aller vite, d’adopter de nouvelles technologies avant les concurrents, d’être les premiers à offrir aux clients quelque chose qu’ils ne savaient pas qu’ils voulaient. De l’autre, la responsabilité envers ces clients, envers leurs données, envers la soutenabilité de long terme. Pas toujours en conflit, mais parfois oui. Et quand ils le sont, le choix n’est jamais évident.
J’ai vu des entreprises bouger trop vite et brûler la confiance des clients avec des implémentations IA pas mûres. J’ai vu des entreprises bouger trop lentement et devenir hors-sujet pendant que le marché changeait autour d’elles. Le tradeoff parfait n’existe pas. N’existe que la capacité à choisir consciemment, en sachant ce que l’on sacrifie et pourquoi.
La valeur n’est pas dans le travail
Ce que j’explore concrètement, c’est une couche backend qui expose les données du client comme MCP server. Un set d’instructions et de configurations pour IA qui sait interroger ce serveur. Une interface de gouvernance où le client peut décider ce que l’IA peut lire et pas, quelle action elle peut accomplir et laquelle non. Un audit trail complet qui trace chaque interaction, chaque décision, chaque erreur.
Le résultat, si ça marche, c’est que le client n’aura plus besoin de nous pour les trois quarts des tâches répétitives. Il aura besoin de nous pour maintenir le système propre, pour ajouter de nouvelles sources de données, pour la gouvernance et la compliance, pour des problèmes qui demandent du jugement humain. C’est un changement de relation : de celui qui fait le travail à celui qui rend le travail automatisable.
J’écris cette phrase et je me rends compte de combien elle est radicale. Je pense à quelque chose qui réduira la quantité de travail que les clients me demanderont. Du point de vue du chiffre d’affaires immédiat, c’est une folie. Du point de vue de la valeur à long terme, je crois que c’est la seule voie sensée. Les clients ne paient pas parce qu’ils aiment payer. Ils paient parce que vous avez quelque chose dont ils ont besoin. Si on peut leur donner la même valeur, ou plus, avec moins de friction, pourquoi ne pas le faire ? Et si tu ne le fais pas, quelqu’un d’autre le fera.
Il y a une phrase que je me répète souvent : la valeur n’est pas dans le travail que tu fais, elle est dans le problème que tu résous. Pendant des années, j’ai mesuré ma valeur en heures, deliverables, features livrées. Maintenant, je me demande si je ne devrais pas la mesurer en problèmes éliminés, friction réduite, capacité rendue aux clients de faire ce qu’ils savent faire le mieux.
La fenêtre temporelle pour ce changement est maintenant, en 2026. MCP est un standard, soutenu par les trois principaux fournisseurs d’IA. Les manques de sécurité se referment progressivement. Les clients commencent à comprendre qu’ils veulent quelque chose comme « parle à ChatGPT et c’est fait ». Qui ne se déplace pas dans cette direction sera mis hors-jeu. Pas demain. Maintenant.
Mais « maintenant » ne veut pas dire « à n’importe quel prix ». Ne veut pas dire sacrifier la sécurité des données pour la vitesse de mise en œuvre. Ne veut pas dire promettre aux clients des fonctionnalités pas encore mûres. Ne veut pas dire ignorer les normes parce qu’elles dérangent. Ça veut dire trouver la manière d’aller vite dans la bonne direction, les yeux ouverts sur où l’on va.
La responsabilité de qui construit
Quelque chose me chatouille particulièrement quand je pense à tout cela. Pas la peur de me tromper techniquement. Elle est là, mais gérable. Quelque chose de plus profond. La conscience que les décisions que nous prenons aujourd’hui comme bâtisseurs de logiciel définissent la relation que les gens auront demain à la technologie. Chaque API qu’on expose, chaque donnée qu’on rend accessible, chaque action qu’on automatise crée un précédent. Cela établit ce qui est normal, ce qui est acceptable, ce qu’on attend.
Je pense à nos clients, des personnes qui dirigent des entreprises, qui ont des salariés, qui servent à leur tour d’autres clients. Quand j’ouvre leurs systèmes à l’IA, je change la manière dont ils travaillent. Je redéfinis quelles compétences seront nécessaires, quels rôles auront du sens, comment leur journée sera structurée. Une responsabilité à ne pas prendre à la légère — et il faut s’attendre à beaucoup plus de résistance, parce que ce qu’on offre n’est pas un logiciel, mais un changement (parfois substantiel) de rôles et de processus internes, et de hiérarchies.
Mais c’est aussi une opportunité extraordinaire. La possibilité de libérer du temps et de l’énergie humaine pour des activités qui demandent vraiment de l’intelligence, de la créativité, du jugement. De réduire le travail répétitif qui consume les personnes sans ajouter de valeur. De rendre les petites entreprises compétitives avec les grandes, parce que l’accès à l’automatisation ne sera plus une question de budget pour des équipes dédiées.
C’est peut-être le tradeoff fondamental. D’un côté, le risque de bâtir des systèmes qui échappent au contrôle, qui créent des dépendances, qui concentrent le pouvoir dans des mains malveillantes. De l’autre, la possibilité de bâtir quelque chose qui aide vraiment les personnes à travailler mieux, à vivre mieux, à consacrer leur temps à ce qui compte.
Et j’ai la conviction que rester immobile n’est pas une option, et la détermination à avancer dans la direction qui me semble juste, un pas à la fois, les yeux ouverts.
Et voilà, c’est ce que je fais.
Si vous reconnaissez cette trajectoire et avez envie de discuter d’où elle pourrait nous emmener, parlons-en.
Ce qu'il faut retenir
Le contrôle qu’offraient les interfaces a toujours été une illusion : une façon de gérer la complexité en réduisant les options au lieu de l’affronter.
MCP a des manques sérieux — authentification, sandboxing, audit — et Gartner estime que 40 % des projets agentic seront annulés d’ici 2027 sans gouvernance solide.
La valeur n’est pas dans le travail que tu fais, elle est dans le problème que tu résous : se mesurer en problèmes éliminés, pas en heures facturées.
Questions & réponses
Quel est le passage de Software 2.0 à Software 3.0 ?
Software 1.0, c’était du code écrit à la main. Software 2.0 (terme de Karpathy), c’étaient des modèles neuronaux entraînés sur des données : le programme implicite est dans les poids, pas dans les lignes. Software 3.0 est l’étape suivante : on n’entraîne pas un modèle dédié, on instruit un foundation model généraliste via prompts et orchestration. La logique se déplace du code, vers les poids, vers le contexte — avec des conséquences radicales sur le cycle de vie du logiciel.
Pourquoi ce passage « nous transforme-t-il », comme le dit le titre ?
Parce qu’il change ce que veut dire « développer ». En Software 1.0, l’aptitude était de traduire des exigences en algorithmes. En Software 2.0, c’était de collecter et étiqueter des données. En Software 3.0, c’est d’écrire des instructions contextuelles (prompts, tool definitions, retrieval) pour des modèles déjà existants. Ce n’est pas qu’un nouvel outil, c’est un autre métier qui demande une autre forme de pensée — plus proche de l’editing/prompting que du coding.
Qu'est-ce que cela veut dire pour les entreprises qui ont investi en Software 2.0 ?
Que beaucoup de projets ML custom bâtis ces cinq dernières années sont en concurrence avec des solutions foundation-model qui font la même chose pour un dixième de l’effort. Cela n’invalide pas rétroactivement l’investissement, mais cela invalide beaucoup de roadmaps futures. Beaucoup d’équipes ML engineering devront réévaluer où leur IP est défendable : sur les données propriétaires, sur les modèles custom, ou sur l’orchestration ?
Qu'est-ce qu'un développeur doit apprendre aujourd'hui pour rester pertinent dans deux ans ?
Pas tant un nouveau langage qu’un nouveau niveau d’abstraction : contextes, prompts, evaluation, tool use, retrieval-augmented reasoning. Le code d’intégration entre ces briques est souvent simple ; le défi est dans le design des pipelines et dans une évaluation rigoureuse. Qui s’arrête au Software 1.0/2.0 reste spécialiste de niches qui se réduisent. Qui ajoute le Software 3.0 se déplace là où la demande croît.
L'auteur
