La conception logicielle à l’ère de l’IA¶

Chapter Info

Calculating... Writing Progress: 60%

!!Nous vivons une période historique unique, sans équivalent dans l’histoire de l’humanité.!! Historiquement, les changements ont été graduels, une génération ressemblant à la précédente. !!Aujourd’hui, nous sommes pourtant dans une période de rupture, où les changements sont soudains et profonds.!! Cette époque est à la fois intimidante et passionnante, car elle nous oblige à nous adapter et à innover d’une façon que nous n’avons jamais connue.

!!La révolution des LLM remodèle le logiciel à chacune de ses couches.!! Les applications, l’interface utilisateur, le rôle du développeur, la structure de l’organisation d’ingénierie et le modèle économique sous-jacent sont tous redéfinis en même temps. !!Contrairement aux transitions précédentes — comme le passage des langages bas niveau aux langages haut niveau ou de l’on-premise au cloud —, ce changement n’améliore pas seulement la façon dont nous construisons le logiciel ; il change ce qu’est le logiciel, qui le construit et comment les entreprises s’organisent autour de lui.!!

La révolution des LLM : une nouvelle ère¶

Quelque chose vient de se briser¶

Pendant quarante ans, le logiciel a été le seul contrat entre les humains et les machines : les humains devaient s’adapter au logiciel — ses formulaires, ses menus, ses commandes, ses APIs — et la machine exécutait exactement ce qu’on lui disait. Chaque interaction était préprogrammée. Chaque comportement était déterministe. L’application était rigide ; l’humain s’adaptait. !!Ce contrat est en train d’être déchiré.!! Les machines ont appris le nôtre. !!Elles lisent désormais l’intention en langage naturel, raisonnent sur les objectifs et composent des actions à travers les services sans que personne n’ait écrit le chemin à l’avance.!!

Le basculement est déjà en cours¶

Ce qui semblait autrefois une possibilité lointaine fait rapidement partie du quotidien du développement logiciel. Les développeurs passent de l’écriture du code eux-mêmes, à la collaboration avec l’IA, puis à la direction de systèmes qui produisent le code à leur place.

2022 : le moment où l’IA est devenue accessible à tous¶

!!En 2022, ChatGPT a rendu l’IA généraliste accessible au grand public.!! Pour la première fois, des millions de personnes pouvaient utiliser un système d’IA puissant et non spécialisé directement via une simple interface de langage : le prompt. Pas de code, pas de configuration, juste une conversation. ChatGPT n’a pas créé la révolution de l’IA à partir de rien. !!Il a transformé des années de progrès techniques en quelque chose que chacun pouvait utiliser directement.!!

D’un seul modèle, le savoir pour tous¶

Pendant des décennies, l’IA a été spécialisée et verrouillée derrière l’expertise — un modèle pour les images, un autre pour la traduction, un autre pour la fraude, chacun entraîné pour une seule tâche et accessible à quelques équipes seulement. !!ChatGPT a fait tomber tout cela dans une seule interface conversationnelle.!! Un seul modèle, interrogé en langage naturel, peut écrire du code, expliquer la médecine, rédiger des contrats, analyser des données ou raisonner à travers les domaines. La spécialisation a cédé la place à l’intelligence généraliste — et la barrière qui gardait le savoir derrière la formation, les diplômes ou la compétence technique s’est simplement ouverte.

Prédire le token suivant¶

Un LLM — un Large Language Model, aussi appelé modèle de fondation — est une fonction mathématique avec des milliards de paramètres. !!À partir d’un texte en entrée, il prédit le token le plus probable : un mot, un fragment ou un signe de ponctuation.!! L’entrée n’est pas seulement la dernière phrase, mais toute la fenêtre de contexte : la conversation, les documents joints, les instructions et les exemples. Le modèle ajoute un token, puis s’exécute à nouveau. Token après token, la réponse grandit. Tous les comportements que nous allons voir — compréhension, raisonnement, choix d’outils et génération de code — reposent sur cette primitive simple.

De la prédiction à la compréhension, au raisonnement et au choix d’outils¶

La prédiction devient utile parce que le modèle compresse des motifs issus de milliards d’exemples. Il ne comprend pas comme un humain, mais il peut prédire à quoi devrait ressembler une réponse qui comprend. Le même mécanisme rend le raisonnement possible. !!Dès qu’il peut comprendre une intention et décomposer une tâche, il peut aussi choisir des outils : recherche, APIs, bases de données, exécution de code ou workflows.!! C’est le fondement des agents — un modèle capable de raisonner et de choisir quelle action doit se produire ensuite.

Comment la prédiction devient un agent de codage IA¶

Le modèle de fondation est aussi entraîné sur du code — de grandes quantités de programmes existants, de documentation, d’APIs, de messages d’erreur, de fichiers de configuration et de patterns de développement. !!La prédiction du token suivant apprend donc non seulement comment les gens écrivent des phrases, mais aussi comment les développeurs écrivent des programmes.!! Il a vu assez d’exemples de fonctions, de classes, de tests, de définitions d’infrastructure et de structures logicielles courantes pour prédire à quoi devrait ressembler une implémentation utile. Intégré dans un agent de codage IA — Claude Code, Cursor, GitHub Copilot — avec les bons outils, le bon contexte et le bon harnais, le même modèle généraliste devient une source d’implémentation.

Réunissez ces quatre comportements — compréhension, raisonnement, choix d’outils et génération de code — et la conséquence n’a plus rien de subtil. Un système qui sait lire l’intention, planifier, appeler des outils et écrire du code n’a pas besoin d’une application à forme humaine entre l’utilisateur et ce qu’il veut faire. La section suivante traite de ce que ce système tue en premier : l’application elle-même.

L’IA ne change pas les fondations de l’ingénierie¶

La surface change, les fondations restent¶

Ce chapitre explore à quel point la révolution de l’IA transforme en profondeur le développement logiciel. !!La forme visible du logiciel change vite, mais les fondations d’ingénierie en dessous restent les mêmes.!! La façon dont nous architecturons les systèmes distribués, modélisons les données, découplons les composants, les sécurisons, les observons, les testons et les exploitons — rien de tout cela n’est une préoccupation d’un autre âge. !!Ce sont les invariants du bon logiciel, et ils tiennent que le code soit écrit par un humain ou par un agent.!!

Réparer ce qui est cassé avant d’ajouter de l’IA¶

L’IA comprime le temps et multiplie la production. !!Quand les fondations sont solides, elle crée un effet de levier, raccourcit les cycles et transforme une ingénierie rigoureuse en avantage concurrentiel. Quand elles sont cassées, elle propage les dégâts à la même vitesse — incidents plus rapides, blast radius plus large, plus de dommages par heure.!! Une entreprise ne peut pas bâtir une vraie stratégie d’IA sur des systèmes d’ingénierie défaillants.

Utiliser l’IA pour réparer les fondations¶

La bonne nouvelle, c’est que l’IA peut aider à réparer les fondations plus vite. !!Elle peut générer les tests manquants, transformer des runbooks manuels en scripts, convertir des opérations en console en code, documenter des workflows cachés, exposer des outils internes sous forme d’APIs et refactoriser la logique dupliquée derrière des abstractions plus propres.!! L’IA ne supprime pas le besoin de rigueur d’ingénierie. Elle rend cette rigueur moins chère à appliquer.

La fin des applications¶

Pendant quarante ans, l’application a été le seul contrat entre les humains et les machines — un produit statique, avec des écrans figés, des workflows figés et un chemin figé que l’utilisateur devait suivre. !!La révolution des LLM brise cela.!! Dès qu’un modèle sait comprendre l’intention, raisonner, appeler des outils et écrire du code, la machine n’a plus besoin d’une surface rigide pour être atteinte. !!Elle peut construire, à la volée, un système dynamique — un agent — qui traduit l’intention de chaque utilisateur en action.!!

L’application, un conteneur statique¶

Une application est un conteneur statique : un nom fixe, une marque fixe, des écrans fixes, des workflows fixes — le tout enveloppant un ensemble de capacités définies, développées et déployées ensemble comme un seul artefact. Réserver un voyage, c’est chercher, réserver, payer, notifier — de nombreuses capacités figées dans une seule surface, et passer d’une application à l’autre est le travail de l’utilisateur. !!Ce conteneur existe pour deux raisons : les utilisateurs ont besoin d’une surface stable pour apprendre et faire confiance, et les machines ne peuvent pas comprendre ce que veulent les gens. Ces deux raisons disparaissent.!!

La plupart des applications disparaîtront¶

Si l’utilisateur est le nouveau centre, l’écran n’est plus le point de rencontre. !!La plupart des applications — les milliards d’écrans, de formulaires, de menus et de parcours de navigation conçus au fil des décennies — étaient des contournements d’une seule limite : les machines ne savaient pas lire l’intention. Cette limite a disparu.!! Le prompt, écrit ou parlé, devient l’interface principale.

L’UI devient à la demande¶

L’UI traditionnelle ne disparaît pas — elle devient secondaire, générée à la demande comme un complément visuel du prompt. Demandez à un agent de comparer trois vols, un tableau apparaît. Demandez-lui de montrer une tendance, un graphique est tracé. !!L’UI n’est plus une surface fixe dans laquelle l’utilisateur doit naviguer ; c’est un artefact temporaire que l’agent produit pour répondre à une question précise, puis jette.!!

La mort de la surface de marque¶

Quand les utilisateurs n’ouvrent plus d’applications, ils ne voient plus de logos, d’écrans de démarrage ni de parcours d’onboarding soigneusement conçus. !!La surface de marque — la couche dans laquelle les entreprises ont investi des milliards en design, marketing et expérience utilisateur — devient invisible.!! L’agent est la nouvelle interface, et il se moque de savoir le logo de quel fournisseur apparaît sur le résultat. C’est une menace existentielle pour les entreprises dont la valeur résidait dans la surface plutôt que dans la substance.

Des applications aux capacités orchestrées par des agents¶

Quand l’application perd sa place d’interface principale, ses capacités ne disparaissent pas. Elles deviennent des briques séparées et appelables : recherche, paiement, réservation, identité, messagerie, analytique, accès aux données. !!L’agent devient la couche qui les compose.!! Au lieu d’ouvrir une application et de naviguer dans ses écrans, l’utilisateur exprime son intention, et l’agent choisit quelles capacités appeler, dans quel ordre et avec quel contexte.

Anatomie d’un agent¶

!!L’agent est le nouveau runtime du logiciel.!! Cette section l’ouvre en grand : ce qui le fait fonctionner, comment il transforme l’intention en action et ce qui le rend assez fiable pour tourner en production.

La limite d’un LLM brut¶

Un LLM brut est un moteur de langage et de raisonnement. Il peut comprendre le langage naturel, déduire l’intention humaine, analyser une situation et décider de ce qui devrait se passer ensuite — mais sans couche d’orchestration autour de lui, il reste limité au conseil. !!Il peut dire à l’utilisateur « vous devriez utiliser cette requête SQL » sans exécuter la requête lui-même.!! Il peut dire « vous devriez envoyer une notification » sans en envoyer une. Il est aussi stateless par défaut : à chaque interaction, l’utilisateur doit lui rappeler le contexte important déjà partagé.

Qu’est-ce qu’un agent¶

Un agent reçoit l’intention de l’utilisateur et la transmet à un LLM. Le LLM interprète cette intention et décompose le problème en étapes. L’agent devient alors l’orchestrateur : pour chaque étape, il rappelle le LLM et lui demande comment l’accomplir. !!Le LLM explique l’action suivante en langage naturel — récupérer ces données, appeler cette API, exécuter cette requête, envoyer ce message. L’agent prend cette instruction, la fait correspondre à un outil ou une capacité exécutable, l’exécute et renvoie le résultat au LLM comme nouveau contexte.!!

Deux patterns : boucles et workflows¶

Les agents prennent généralement l’une de deux formes. !!Les agents à boucle sont entièrement autonomes : ils observent, raisonnent, agissent, évaluent et replanifient en continu.!! Ils peuvent changer de stratégie en cours de tâche, réessayer après un échec et s’adapter quand l’environnement évolue. Flexibilité maximale — prévisibilité minimale. Les agents à workflow sont l’inverse : leur chemin est défini à l’avance par les ingénieurs.

Le fossé entre la démo et la production¶

Créer un agent est facile aujourd’hui : un prompt, quelques outils, et une démo convaincante apparaît vite. !!Le plus dur commence quand la démo doit devenir un système sur lequel les gens comptent.!! Dans une démo, le chemin est étroit, le contexte est maîtrisé et les erreurs sont tolérées. En production, l’agent rencontre des entrées désordonnées, des données partielles, des outils lents, des frontières de permissions et des utilisateurs qui attendent des résultats reproductibles.

La fiabilité vient de l’orchestration, pas du modèle¶

!!La fiabilité ne se construit pas dans le modèle — elle se construit autour de lui.!! La prévisibilité vient de ce qui entoure le LLM : contexte métier, contrats d’outils, permissions, points de validation, mémoire à portée limitée, gouvernance, observabilité et responsabilité claire. Le modèle reste créatif ; le système autour de lui reste contrôlable.

De l’agent à l’expert¶

La fiabilité n’est que le premier seuil. Un agent fiable peut s’exécuter sans casser le workflow. Un agent expert est différent : on peut lui confier du jugement dans un domaine précis. Il a vu assez de cas réels, traité assez de cas limites et accumulé assez de preuves dans le temps pour que l’organisation le traite moins comme un outil que comme un spécialiste. Cette promotion — de l’agent exécutable à l’expert de domaine de confiance — est le vrai basculement dont parle cette section.

Qu’est-ce qu’un expert ?¶

Un expert n’est pas un agent avec un modèle plus gros ou plus de données d’entraînement. !!C’est un agent qui a prouvé sa compétence dans un domaine précis.!! L’expertise, c’est un jugement constant, une solide compréhension du domaine et un historique mesurable de traitement de scénarios réels avec moins de supervision.

Gagner le statut d’expert¶

Tous les agents ne deviennent pas des experts. !!Le statut d’expert doit se gagner par des preuves : une précision au-dessus d’un seuil défini, une gestion fiable des cas limites, de faibles taux d’erreur en production et une revue humaine positive.!! Quelques exécutions réussies ne suffisent pas — la promotion exige du volume, de la constance et une confiance statistique sur des tâches réelles.

Chaque expert a un responsable¶

Un expert n’opère pas en isolation. !!Chaque expert a un responsable humain — quelqu’un de redevable de sa trajectoire d’apprentissage, de ses standards de qualité et de sa justesse dans le domaine.!! Le responsable coache l’expert dans la durée, affine son jugement, corrige ses erreurs et approuve les nouvelles capacités avant leur mise en production.

Les experts apprennent du feedback¶

Au-delà du coaching humain, un expert s’améliore grâce au feedback — non pas en réentraînant son modèle, mais en mettant à jour ce qui l’entoure : mémoire, règles, prompts, exemples, evals, routage. !!Il observe les résultats de ses propres décisions, détecte quand ses prédictions divergent de la réalité et s’ajuste d’après la télémétrie de production, les corrections et les patterns observés sur des milliers de tâches similaires.!!

La fin des développeurs¶

Si les applications meurent et que les agents prennent leur place, la question suivante s’impose : qui les construit, et qui construit les capacités qu’ils appellent ? Pendant quarante ans, la réponse était les développeurs — des humains tapant du code ligne par ligne. !!Cette réponse change vite.!! Le rôle ne disparaît pas, mais le travail qui le définissait, si.

Le développeur est mort¶

Dans la plupart des entreprises, c’est déjà une réalité. !!Les développeurs n’écrivent plus de code — ils utilisent l’IA pour générer du code à partir de leurs spécifications.!! Des outils comme Cursor et Claude Code ne se contentent pas d’autocompléter ; ils raisonnent sur le contexte du projet, proposent des changements multi-fichiers et produisent une implémentation substantielle à partir de l’intention.

Vive les ingénieurs¶

Le développeur est mort, mais l’ingénieur est plus essentiel que jamais. !!Écrire du code n’a jamais été le plus dur — comprendre le problème, si.!! Les ingénieurs supervisent, prennent les décisions de haut niveau, définissent les contraintes et valident que ce qui est généré correspond à la réalité métier.

Le nouveau rythme de l’ingénierie¶

Le rythme quotidien du métier s’est inversé. !!L’ancienne boucle était réfléchir, taper, compiler, déboguer — la plupart des heures passées à taper. La nouvelle boucle est intention, prompt, revue, affinage — la plupart des heures passées à lire ce qui a été généré et à décider d’accepter, de rejeter ou d’orienter.!! Les sessions sont plus courtes, l’itération plus rapide, et le goulot d’étranglement passe de la vitesse d’écriture à la vitesse de jugement.

La courbe d’apprentissage du codage avec agents¶

Les ingénieurs commencent généralement par l’enthousiasme : l’agent écrit du code, explique les erreurs et produit des prototypes rapidement. !!Puis la réalité apparaît : le code peut manquer de contexte, tester la mauvaise hypothèse ou échouer une fois connecté au vrai système.!! C’est cela, la vraie courbe d’apprentissage : de l’enthousiasme à la discipline, où les ingénieurs matures cessent de demander seulement à quelle vitesse l’agent peut coder et se demandent comment rendre le workflow fiable, reproductible et sûr.

S’adapter ou être remplacé¶

La vérité plus dure, c’est que l’ingénieur qui refuse de changer est celui qui est remplacé — pas par l’IA directement, mais par un autre ingénieur qui utilise bien l’IA. !!Le changement n’est pas optionnel et il n’est pas lent.!! Les ingénieurs qui continuent à taper ligne par ligne, qui traitent l’IA comme une curiosité plutôt que comme un outil quotidien, qui défendent l’ancien savoir-faire comme si la vitesse de génération n’avait pas été multipliée par dix — ceux-là deviennent moins compétitifs à mesure que les organisations apprennent à produire plus avec moins de personnes.

Les ingénieurs construisent des capacités, pas des écrans¶

À mesure que les UIs traditionnelles passent à l’arrière-plan, ce que construisent les ingénieurs change aussi. !!L’accent passe de la conception d’écrans et de parcours utilisateur à la création d’APIs, d’extensions MCP, de services et de capacités que les agents et d’autres systèmes peuvent consommer.!! Les ingénieurs — avec l’aide de l’IA — continuent de construire l’ossature fonctionnelle : logique métier, pipelines de données, intégrations, contrôles de sécurité et infrastructure.

Le cycle de vie logiciel natif IA¶

L’IA ne supprime pas le cycle de vie du développement logiciel. Elle change la manière dont chaque étape est réalisée. Les exigences deviennent plus explicites, la conception plus exploratoire, l’implémentation générée, les tests continus, la revue plus importante, et les opérations alimentent directement le développement. !!Le cycle de vie demeure — mais l’équilibre du travail en son sein se déplace.!!

Les exigences deviennent le point de départ¶

Quand l’implémentation devient bon marché, les exigences floues deviennent chères. !!La qualité du résultat dépend de plus en plus de la clarté avec laquelle le problème, les contraintes, le comportement attendu et les critères d’acceptation sont exprimés.!! Les ingénieurs passent moins de temps à traduire les exigences en code et plus de temps à s’assurer que les exigences elles-mêmes sont assez précises pour qu’un agent puisse agir dessus.

Laissez l’agent clarifier vos besoins et attentes¶

La plupart d’entre nous ne savons pas exactement ce que nous voulons avant qu’on nous le demande. !!Laissez l’agent clarifier vos envies et vos besoins : indiquez-lui que sa mission, pour l’instant, n’est pas de construire la solution, mais de vous aider à préciser votre demande.!! Cela renverse la dynamique : l’agent pose les questions, l’humain répond, et la génération ne commence que lorsque l’intention est clairement définie.

La conception devient plus rapide et plus exploratoire¶

L’IA rend l’exploration d’alternatives bon marché. Un ingénieur peut demander plusieurs architectures, comparer les compromis, remettre en cause les hypothèses et itérer avant de s’engager dans une direction. !!La conception consiste moins à produire une réponse unique qu’à évaluer rapidement de nombreuses réponses possibles.!! Le jugement humain reste essentiel, car le modèle peut proposer des options, mais il n’en assume pas les conséquences.

L’implémentation devient génération¶

L’implémentation est l’étape qui change le plus visiblement. !!Au lieu de traduire manuellement chaque décision en code, les ingénieurs décrivent de plus en plus l’intention et laissent des agents de codage produire l’implémentation.!! Le travail passe de la frappe de syntaxe à la fourniture de contexte, la définition de frontières, le pilotage de l’agent et la décision de savoir si le résultat généré satisfait réellement la conception.

Les tests se rapprochent de la génération¶

Quand le code peut être généré en quelques secondes, les tests ne peuvent plus rester une activité lente effectuée après coup. !!Les tests font partie de la boucle de génération : générer, tester, inspecter l’échec, affiner, et générer à nouveau.!! L’IA peut créer des cas de test, les exécuter, investiguer les échecs et proposer des correctifs, mais une validation indépendante reste essentielle.

Le déploiement devient une autre action d’agent¶

Le déploiement n’est plus nécessairement une étape manuelle distincte après le développement. Avec des pipelines, de l’infrastructure as code, des contrôles de politiques et des mécanismes de rollback fiables, un agent peut préparer et exécuter une release dans le même workflow. !!Le changement important n’est pas le déploiement autonome en soi, mais le fait que le déploiement devienne une capacité appelable, régie par des règles explicites.!!

Les opérations referment la boucle¶

La production n’est plus la fin du cycle de vie. Logs, traces, incidents, comportement des utilisateurs et performances deviennent un contexte que les agents peuvent analyser en continu. !!Le feedback de production revient directement dans les exigences, l’implémentation et les tests.!! Un échec peut déclencher une investigation, un correctif proposé, de nouveaux tests et un nouveau changement sans reconstruire le contexte de zéro.

Le cycle de vie devient une boucle continue¶

L’ancien cycle de vie était un relais — chaque étape passait le témoin à la personne ou l’équipe suivante, dans un seul sens. Le cycle natif IA enroule cette ligne en boucle : intention → conception → génération → validation → déploiement → observation → amélioration, qui se nourrit d’elle-même. !!L’IA comprime le temps entre les étapes jusqu’à presque zéro, mais les humains gardent la main sur les deux choses qui ne s’automatisent jamais : quoi construire, et ce qui est assez bon pour être livré.!!

Garder le code sous contrôle¶

!!La génération devient bon marché, donc la base de code grandit plus vite que quiconque ne peut la lire.!! Ce n’est pas une raison de ralentir — c’est une raison de changer les disciplines qui maintiennent le code en bonne santé. Volume, cohésion et ownership appellent de nouvelles réponses quand l’auteur n’est plus une seule équipe humaine.

Imposer la cohésion par des contrats¶

Des agents différents écrivent du code différent, sauf si on leur donne les mêmes rails. !!La cohésion n’est pas une affaire d’espoir — elle s’impose par des contrats explicites : un guide de style partagé que les agents lisent, des patterns canoniques pour chaque forme récurrente (erreurs, retries, logging, accès aux données) et des linters qui font échouer le build quand un agent invente sa propre variante.!!

Posséder les décisions, pas les lignes¶

L’ancien modèle — un ingénieur, un fichier, un responsable — s’effondre quand les agents écrivent l’essentiel du code. !!La nouvelle discipline remonte l’ownership d’un niveau : les humains possèdent les décisions et les contrats qui façonnent le code, et le code suit.!! Chaque module a un humain responsable qui a défini son intention, approuve son interface et répond quand il casse.

L’entreprise agentique¶

Une entreprise agentique n’est pas simplement une société qui a ajouté des outils d’IA. !!C’est une organisation dont le travail circule désormais entre humains, agents et plateformes.!! Les agents absorbent le travail routinier — tri du support, préparation de réunions, coordination administrative, recherche, tableaux de bord, migrations — tandis que les humains gardent le jugement, les relations, les exceptions et la responsabilité.

L’IA doit repenser tout le cycle de vie logiciel¶

L’IA ne peut pas créer toute sa valeur en accélérant seulement la génération de code. Si l’implémentation devient considérablement plus rapide alors que les exigences, la validation, le déploiement, le feedback utilisateur et la prise de décision restent inchangés, le goulot d’étranglement se déplace simplement à l’étape suivante et le travail généré s’accumule plus vite que l’organisation ne peut l’absorber. Une entreprise agentique doit pouvoir accélérer chaque étape du cycle de vie logiciel — y compris la plus difficile à faire passer à l’échelle : le feedback utilisateur.

Les humains pilotent, les agents exécutent¶

Repenser tout le cycle de vie pour l’IA, c’est d’abord redéfinir le rôle humain à chaque étape. Les humains passent de l’exécution directe de chaque tâche à la définition de l’intention, la fixation des contraintes, les décisions de jugement et la définition de ce qu’est un bon résultat. Les agents exécutent une part plus grande du travail, tandis que les plateformes fournissent les contrôles qui rendent cette collaboration sûre et scalable.

L’entreprise devient une couche d’orchestration¶

Le centre de gravité passe des produits à l’orchestration. !!L’entreprise livre toujours du logiciel, mais sa fonction profonde devient d’acheminer le travail entre les humains, les agents et les systèmes sur lesquels le business tourne déjà : dossiers clients, files de tickets, pipelines, validations et systèmes financiers.!!

La capacité par humain augmente¶

Pendant des décennies, les entreprises ont mesuré leur capacité par les effectifs. Dans une entreprise agentique, ce ratio change. !!Moins de personnes peuvent produire davantage, car les agents absorbent le travail répétitif autour d’elles.!! La mesure pertinente n’est plus seulement l’effectif — c’est la capacité par humain.

Petites équipes, portée d’entreprise¶

!!Quand une seule personne peut diriger une flotte d’agents, l’écart entre une petite équipe et une grande entreprise se réduit.!! Une petite société peut livrer, supporter et exploiter à une échelle qui exigeait autrefois des équipes spécialisées. L’avantage du géant devient les données, la distribution, la confiance et le contexte interne.

De l’employé à l’opérateur d’agents¶

Dans une entreprise agentique, le rôle humain monte d’un cran. !!Les gens n’exécutent plus chaque tâche directement ; ils lancent, supervisent, réorientent et acceptent le travail des agents.!! Un commercial est briefé avant une réunion. Un responsable support voit les cas routiniers déjà triés. Un ingénieur reçoit implémentation, tests et investigations d’agents spécialisés, puis décide de ce qui peut être mergé en sécurité.

Les capacités se connectent via le business existant¶

Les agents ne deviennent utiles que lorsqu’ils peuvent agir à travers les systèmes où vit déjà le business — dossiers clients, files de support, validations, pipelines, facturation et documents. !!Ces systèmes doivent devenir des capacités appelables avec des contrats clairs.!! MCP — le Model Context Protocol — est une des voies émergentes pour les exposer aux agents.

Les données client restent chez le client¶

Pendant deux décennies, le SaaS a concentré les données client dans les systèmes du fournisseur — le prix d’utilisation du produit. Ce modèle s’inverse. !!Le client garde ses données, les expose via ses propres connecteurs sous son propre contrôle d’accès, et laisse les agents — du fournisseur, tiers ou les siens — les interroger à la demande.!!

Le savoir de l’entreprise devient interrogeable¶

!!Chaque employé est augmenté par un agent capable d’atteindre le savoir organisationnel en le demandant.!! Un commercial entre en réunion déjà briefé. Un manager demande ce qui a changé pendant la nuit. Un agent du support voit l’historique, la politique et la résolution probable sans fouiller cinq systèmes.

Le contexte interne est le vrai actif¶

Si les mêmes modèles sont disponibles pour tous, ce qui rend une entreprise plus intelligente qu’une autre, c’est le contexte que le modèle peut utiliser. !!Comment cette entreprise vend, pourquoi ce ticket a été escaladé, quelle politique s’applique, quelle décision a été prise la dernière fois.!! Aujourd’hui, ce contexte est dispersé entre tickets, runbooks, fils de discussion, code et tableaux de bord. Les entreprises qui gagnent en font un substrat appelable : indexé, soumis à permissions, à jour et traçable.

L’IA met fin à la chasse à la root cause¶

L’analyse de root cause a toujours été l’un des coûts récurrents les plus lourds de l’exploitation d’une entreprise — la plupart des pannes remontent à un changement interne, et les ingénieurs passent l’essentiel du temps d’incident à jouer les détectives entre logs, tickets, déploiements et tableaux de bord pendant que les SLAs se brisent en silence. !!C’est exactement là que l’IA excelle : avec le bon contexte, les bonnes connexions et les bonnes sources, un agent corrèle symptôme, déploiement et changement en quelques secondes — réduisant des heures de forensique à une réponse instantanée.!! Le goulot n’a jamais été la compétence humaine ; c’était des systèmes déconnectés.

Les humains restent au centre¶

Les humains ne disparaissent pas de ce tableau, car les problèmes que résout le logiciel sont des problèmes humains. !!Un patient ne veut pas un workflow — il veut aller mieux. Un chef d’entreprise ne veut pas un CRM — il veut que ses clients reviennent.!! Un voyageur ne veut pas un itinéraire — il veut un bon voyage. Définir ce que « bien » veut dire est un travail humain, et il ne se délègue pas.

Ce que l’entreprise agentique exige¶

La vision ne tient que si les rails sont posés. !!Les agents ne peuvent pas tourner à grande échelle sur du savoir tribal, des outils accessibles uniquement par console et la configuration privée de chaque équipe.!! Trois prérequis séparent une présentation PowerPoint d’une vraie entreprise agentique : des tests qui attrapent ce que l’IA livre, une plateforme que les agents savent parcourir, et un système où tout est du code.

Sans tests, vous jouez au casino¶

Livrer sans tests, c’est jouer — vous pariez que votre code fonctionne sans aucun moyen de le prouver. L’IA rend ce pari mortel. !!Un agent peut générer du code qui compile, a l’air plausible et reste faux.!! Il peut aussi générer des tests qui valident la même hypothèse erronée, de sorte qu’un build vert peut simplement prouver que l’agent a testé sa propre incompréhension.

Les plateformes internes de développement sont essentielles¶

Tout exposer sous forme d’APIs ne fonctionne que si ces APIs vivent dans un endroit cohérent. Sans vraie plateforme interne de développement, chaque équipe câble son propre pipeline, son propre déploiement, sa propre stack d’observabilité — et l’agent n’a aucune surface cohérente sur laquelle agir. !!Une plateforme interne solide — paved paths, golden templates, infrastructure en self-service, une seule façon de déployer, une seule façon d’observer — est ce qui transforme des capacités dispersées en un système navigable.!!

Tout visible, tout en code¶

Les troisième et quatrième fondations sont les deux faces d’une même règle : si ce n’est pas appelable, l’IA ne peut pas l’utiliser ; si ce n’est pas dans le code, l’IA ne peut pas le lire. !!Les capacités cachées derrière du savoir tribal, des outils réservés à la console, des scripts internes, des runbooks qui vivent dans la tête de quelqu’un — rien de tout cela ne peut être orchestré par un agent.!! La discipline consiste à exposer chaque opération sous forme d’API, et à garder chaque configuration — infrastructure, déploiements, politiques, monitors, tableaux de bord, règles d’accès — dans le contrôle de version, relue comme l’application elle-même.