Hier, avec des collègues, on nous a annoncé que nous allions devoir intégrer au système d'information des applications générées avec l'IA par les métiers.
J'en ai fait des cauchemars cette nuit. Dans mon rêve, j'étais appelé d'astreinte. Je devais analyser du code écrit dans un langage que je ne maîtrisais pas et que je n'avais pas choisi, avec des dépendances non vérifiées, des paquets piégés par typosquattage et des composants dans de vieilles versions.
Au réveil, la question restait : qui allait assumer ces applications une fois en production ?
Le besoin reste à clarifier. Mais les choix techniques, eux, sont déjà faits.
Le prototype devient critique sans décision de prise en charge
Je comprends l'enthousiasme. Vous décrivez une idée à une IA, une interface apparaît, quelques clics fonctionnent. Un problème qui attendait depuis des mois semble enfin trouver sa solution.
Seulement, cette démonstration ne répond pas aux questions qui arrivent dès qu'on veut en faire un service utilisé dans l'entreprise. Comment les utilisateurs se connectent-ils ? Qui peut voir quelles données ? Où sont stockés les secrets ? Comment sauvegarder, restaurer, mettre à jour, diagnostiquer un incident ? Qui reprend le sujet quand la personne à l'origine de l'application change de poste ?
Ces questions ne disparaissent pas parce que le code a été produit rapidement. Elles deviennent la charge de l'équipe qui accepte de le reprendre.
« Ça marche sur mon poste » décrit une démonstration réussie. Cela ne décrit pas un service que nous sommes prêts à exploiter.
Cette dérive est aussi décrite par Thoughtworks dans son Technology Radar consacré au shadow IT accéléré par l'IA. Le Radar recommande de distinguer les expérimentations jetables des processus critiques, de fournir des environnements d'essai contrôlés et de rendre les solutions existantes visibles. Je retiens surtout ce point : il faut organiser le passage de l'expérience au service durable, plutôt que le laisser se produire par défaut.
Les choix techniques arrivent avant la discussion
Quand une application arrive avec des langages ésotériques et des dépendances encore plus étranges, quelqu'un doit ensuite en assumer la maintenance et la sécurité.
Une technologie absente de notre catalogue peut être pertinente. Encore faut-il examiner ce qu'elle apporte et ce qu'elle nous coûtera. Avons-nous les compétences pour la maintenir ? Nos outils savent-ils la construire et l'analyser ? Qui suivra ses mises à jour ? Pourquoi ajouter une nouvelle pile si une solution déjà maîtrisée répond au besoin ?
Quand ces questions se posent après la livraison, la discussion commence avec une pression supplémentaire : l'application existe, quelqu'un l'a montrée, des utilisateurs l'attendent. Revenir sur ses fondations devient plus difficile.
Et l'effet se cumule. Une application de plus, c'est un dépôt, un environnement, des dépendances, des accès et un cycle de vie supplémentaires. À force, nous constituons un patrimoine de code dont la maintenance dépasse les moyens disponibles.
Le coût de génération du code ne donne aucune mesure du coût de sa prise en charge.
La dette de compréhension s'ajoute à notre dette existante
C'est le point qui manque souvent dans les démonstrations : les équipes qui doivent reprendre ces applications ne sont pas en train d'attendre du travail. Nous avons déjà nos propres dépendances à mettre à jour, nos composants vieillissants, nos défauts à corriger et nos services à fiabiliser.
Nous avons déjà du mal à résorber cette dette. Ajouter des applications conçues en dehors de tout cadre, sans temps ni moyens pour les reprendre, augmente encore la charge. Chaque reprise se paie par un arbitrage : quel correctif attendra ? Quelle mise à jour sera reportée ? Quel chantier de fiabilisation sera sacrifié ?
Une application générée rapidement ne crée pas la capacité de maintenance qui va avec.
Et nous ne pouvons pas promettre une reprise sans limite. À force de demander aux mêmes équipes d'absorber leur dette et celle qui arrive de partout, on finit par épuiser les personnes qui connaissent encore le système. Pour ma part, je refuse que leur disponibilité serve de variable d'ajustement à toutes les expérimentations.
Addy Osmani décrit une autre dimension de cette charge dans The 80% Problem in Agentic Coding : la dette de compréhension. Le code est produit, parfois les tests passent, mais ceux qui l'acceptent n'en maîtrisent plus suffisamment le fonctionnement. Ce billet est un retour d'expérience ; ses pourcentages ne constituent pas une mesure universelle de ce que l'IA peut livrer.
J'en tire une conséquence pour nos organisations : reprendre une application suppose aussi de financer le temps nécessaire pour la comprendre, l'exploiter et la maintenir. Un dépôt transmis ne vaut pas un transfert de compétences.
Qui répondra quand l'application tombera ?
Dans I still care about the code, Birgitta Böckeler propose de regarder le code généré depuis la responsabilité d'astreinte : quel changement accepterions-nous de déployer si nous devions personnellement en gérer les conséquences ? Elle insiste notamment sur la confiance dans les tests et sur la capacité à détecter les problèmes.
Cette question remet l'exploitation au milieu de la discussion. Lors d'une démonstration, nous voyons les fonctionnalités qui marchent. En incident, il faut comprendre ce qui ne marche plus, retrouver un changement, protéger les données et rétablir le service.
Prenons une situation fictive : l'outil de validation des achats ne répond plus le jour de la clôture. Son créateur n'est pas disponible. L'équipe appelée découvre un framework qu'elle ne connaît pas, des journaux insuffisants et aucune restauration vérifiée. L'application a été montrée, utilisée, puis considérée comme acquise. La capacité à la dépanner n'a jamais été organisée.
Le problème était déjà là avant la panne : personne n'avait accepté cette responsabilité avec les compétences, les accès et le temps nécessaires.
À deux heures du matin, ce ne sera pas nécessairement la personne qui a généré l'application avec l'IA qui se lèvera. Ce sera l'équipe de garde, avec la responsabilité de rétablir un service qu'elle n'a parfois ni choisi ni accepté de prendre en charge.
Je trouve ce transfert de responsabilité intolérable lorsqu'il est imposé. Expérimenter ne donne pas le droit d'engager le sommeil, le temps et la responsabilité professionnelle des autres. Si une application doit être couverte par l'astreinte, cette prise en charge se discute, se prépare et se finance avant sa mise en production.
Une démonstration réussie ne vaut pas un engagement de support. Avant de parler de mise en production, je veux savoir quelle équipe accepte le service, comment elle le surveille, comment elle revient en arrière et ce qu'elle doit pouvoir restaurer. Ces réponses se construisent avec elle ; elles ne peuvent pas lui être imposées après livraison.
Ce que j'attends des métiers avec l'IA
C'est précisément sur les livrables attendus depuis des années que l'IA pourrait nous faire gagner du temps.
Je voudrais recevoir une description du problème, des exemples représentatifs, les règles qui ne doivent pas être enfreintes et des résultats attendus que nous pouvons vérifier. Le métier possède une connaissance que ni les développeurs ni l'IA ne peuvent inventer : ce qui se passe vraiment dans son activité, y compris quand les choses se passent mal.
Prenons un cas fictif : un outil de validation de demandes d'achat. « Il faut un formulaire et un bouton Valider » laisse presque tout à décider. Qui valide ? Selon quel montant ? Que se passe-t-il si le responsable est absent ? Peut-on modifier une demande après validation ? Faut-il conserver l'historique d'un refus ?
Voici le genre de travail que je proposerais de faire avec l'IA :
À partir de mes notes, aide-moi à décrire le processus de validation des demandes d'achat. Identifie les acteurs, les règles de gestion, les exceptions et les questions sans réponse. Propose des critères d'acceptation vérifiables. N'invente aucune règle : signale explicitement les décisions qui restent à prendre. Ne génère pas de code.
Le résultat doit ensuite être relu et corrigé par le métier. Un document bien rédigé peut encore contenir une règle fausse. L'intérêt est de rendre les ambiguïtés visibles et de faciliter la discussion.
Par exemple, une fois la règle confirmée, un critère pourrait devenir :
Une demande dépassant le seuil autorisé pour un responsable ne peut pas être approuvée par ce responsable. La tentative est refusée et la demande conserve son état précédent.
Nous pouvons discuter cette règle, en déduire les droits nécessaires et construire un test. Voilà un livrable qui fait avancer le projet.
Je n'attends pas un cahier des charges de cent pages figé avant le premier échange. Je veux des exemples assez précis pour commencer ensemble, puis les corriger à mesure que nous apprenons. Les critères d'acceptation métier décrivent le résultat attendu ; les équipes techniques construisent les tests qui vérifient l'implémentation. Les deux se travaillent ensemble.
L'IA peut aider à préparer cette discussion. Elle ne doit pas transformer les zones d'ombre du métier en décisions implicites dans le code.
Nous aussi, nous générons du code avec l'IA
J'utilise l'IA pour produire du code. Mon propos n'a rien d'un appel à revenir en arrière, et le vibe coding a sa place quand on sait ce qu'on en fait.
Mais je veux que cette génération parte du besoin validé et des contraintes du système dans lequel le logiciel va vivre : identité, sécurité, architecture, échanges avec les services existants, données, déploiement et exploitation.
Dans Agentic Engineering, Martin Fowler distingue la génération supervisée du code d'une pratique où l'on cesse de regarder ce qui a été produit. L'humain reste responsable du comportement et de la structure du logiciel. Cela rejoint mon exigence : utiliser l'IA ne dispense pas de pouvoir expliquer et vérifier ce qu'on livre.
Ces exigences doivent être accessibles aux agents : instructions de projet, skills, modèles de dépôts et décisions d'architecture. Un agent ne peut pas respecter une convention interne qui ne lui a jamais été fournie.
Cela ne suffit pas. Écrire « respecte nos exigences de sécurité » dans un fichier ne prouve rien. Il faut examiner le code, tester les comportements, contrôler les dépendances et vérifier la configuration déployée. Les règles importantes doivent devenir des vérifications reproductibles chaque fois que c'est possible. C'est aussi ce que décrivent les anti-patterns DevOps : une automatisation que personne ne relit n'est pas une automatisation, c'est un report de problème.
Simon Willison souligne dans Vibe engineering que les agents bénéficient de pratiques déjà solides : tests automatisés, documentation, gestion de versions, revues et intégration continue. Autrement dit, mettre un agent devant un dépôt ne remplace pas le travail sur son environnement de développement.
Le Secure Software Development Framework du NIST fournit un point d'appui à cette démarche : définir les exigences de sécurité et intégrer les pratiques de développement sécurisé au cycle de vie du logiciel. Le cadre que je défends ici pour répartir le travail avec les métiers reste ma proposition d'organisation.
Un prototype ne doit pas engager la production par défaut
Une maquette peut être utile pour expliquer une interaction ou faire apparaître un besoin mal compris. Mais il faut nommer ce qui est montré et ce que cela engage.
Pour moi, un prototype métier reste un support de discussion dans un environnement autorisé, avec des données fictives. Il ne devient pas une application de production parce qu'il a convaincu en réunion. Son code peut être évalué ; sa reprise ne doit pas être considérée comme acquise.
La décision d'industrialiser vient avec un responsable, un périmètre, une analyse technique et une capacité de maintenance. Elle peut conduire à reprendre une partie du prototype, à le réécrire ou à retenir un service existant. La démonstration aide à comprendre le besoin ; elle ne doit pas décider seule de la solution.
Le cadre doit aussi rendre le bon chemin praticable
Les équipes techniques ont une responsabilité dans cette situation. Si faire examiner un besoin prend des mois, les personnes chercheront un moyen d'avancer. Une interdiction sans solution accessible ne réglera pas cette frustration.
Je défends donc un cadre simple, annoncé avant le développement :
| Moment | Ce que je veux obtenir |
|---|---|
| Expression du besoin | Un problème concret, des utilisateurs identifiés, des exemples et des critères d'acceptation validés par le métier. |
| Choix de la solution | Une vérification des services existants, des données concernées et des contraintes d'intégration. |
| Développement | Une pile technique assumée, les exigences du SI accessibles aux agents et des contrôles exécutés sur le résultat. |
| Mise en service | Un responsable de maintenance, des accès maîtrisés, un déploiement reproductible et des procédures d'exploitation vérifiées. |
Ce cadre doit être proportionné. Un outil local manipulant des données fictives n'appelle pas le même examen qu'un service partagé qui traite des informations sensibles. Mais cette distinction doit être explicite, pas découverte après la diffusion de l'application. C'est le même arbitrage que celui des compromis de sécurité : une règle trop lourde pour son risque se contourne.
Les métiers doivent savoir comment obtenir de l'aide. Les équipes techniques doivent pouvoir expliquer leurs contraintes et proposer un chemin utilisable. Et toute nouvelle application doit avoir quelqu'un pour en assumer la durée.
Le gain de temps doit se mesurer jusqu'à l'exploitation
Ce que je refuse, c'est qu'une génération rapide de code devienne une obligation de reprise pour les autres équipes. Avant d'ajouter une application, il faut pouvoir répondre à une question : quelle capacité avons-nous réellement pour la maintenir, alors que le patrimoine existant demande déjà du travail ?
Sans réponse, nous n'avons pas démontré un gain collectif. Nous avons déplacé la charge. Le prototype est devenu un service sans décision explicite, le code a grandi sans compréhension suffisante, et les incidents ont trouvé une équipe d'astreinte par défaut. Voilà les trois dérives que notre cadre doit empêcher.
L'IA nous donne déjà un moyen de mieux préparer les projets : rendre les besoins discutables, expliciter les exceptions, construire des critères d'acceptation et produire du code dans un cadre connu. Utilisons cette capacité avant d'ajouter une application au patrimoine de l'entreprise.
Votre gain de temps ne doit pas devenir notre dette technique.
Et si demain les prix, les quotas ou les produits de nos fournisseurs d'IA changent, serons-nous encore capables de comprendre, maintenir et exploiter nos applications ?
Sources et lectures pour prolonger
Ces textes nourrissent la réflexion ; le constat de départ et les choix d'organisation proposés dans ce billet restent les miens.
- Birgitta Böckeler, I still care about the code, 9 juillet 2025 : la responsabilité d'astreinte comme critère pour évaluer les changements générés.
- Addy Osmani, The 80% Problem in Agentic Coding, 28 janvier 2026 : la dette de compréhension derrière la génération de code.
- Martin Fowler, Agentic Engineering, 21 mai 2026 : la responsabilité humaine dans le développement avec des agents.
- Simon Willison, Vibe engineering, 7 octobre 2025 : les pratiques d'ingénierie qui permettent d'utiliser les agents avec exigence.
- Thoughtworks, AI-accelerated shadow IT, mise à jour d'avril 2026 : les risques et l'encadrement des initiatives hors du circuit informatique.
- NIST, Secure Software Development Framework, SP 800-218, février 2022 : les pratiques de développement sécurisé sur le cycle de vie du logiciel.