Vos développeurs utilisent peut-être l'IA depuis dix-huit mois. Et vos équipes, elles, attendent encore l'approbation du comité.

Ethan Mollick, professeur à la Wharton School et auteur de Co-Intelligence, résume en une phrase une situation qu'il rencontre en permanence dans ses consultations : « Il est stupéfiant de constater combien d'entreprises ont encore l'IA effectivement bloquée par les départements IT et juridique. » Ce qu'il observe n'est pas un retard technologique — c'est un fossé organisationnel. Dans la même industrie, à quelques kilomètres de distance, une entreprise exploite l'IA depuis dix-huit mois tandis qu'une autre a mis en place un comité qui doit approuver chaque cas d'usage individuellement, et s'inquiète encore que les modèles s'entraînent sur ses données — une crainte que Mollick réfute directement : ce n'est pas le cas avec les versions entreprise¹.

Ce fossé ne concerne pas les entreprises qui hésitent encore à tester l'IA générative. Il concerne celles qui s'apprêtent à déployer l'agentic coding — la prochaine étape, où des agents autonomes écrivent, testent et committent du code en continu. La question n'est plus « faut-il y aller ? » mais « par où commencer concrètement, sans répéter les erreurs des pilotes qui n'ont jamais passé la production ? »

La majorité des pilotes IA échouent — et ce n'est pas un problème de modèle

Le chiffre publié par le MIT NANDA en août 2025 est saisissant : 95% des pilotes IA en entreprise ne livrent aucun impact P&L mesurable². 80% des organisations ont piloté ChatGPT ou Copilot. À peine 5% passent en production sur des systèmes enterprise-grade.

La tentation immédiate est d'attribuer cet échec au modèle, à l'outil, à la maturité de la technologie. C'est se tromper de diagnostic. Boris Cherny, créateur de Claude Code chez Anthropic, ne cache pas que les six premiers mois de Claude Code n'étaient « pas très bons, à peine utilisables ». L'inflexion est venue avec Opus 4 en mai 2025 — et depuis, chaque nouvelle version du modèle a accéléré la courbe³. Le modèle, aujourd'hui, n'est plus le goulot.

Le goulot, c'est l'organisation. Mollick l'écrit explicitement : le facteur décisif est la volonté d'un dirigeant — souvent le CEO, pas toujours — d'assumer le risque et la responsabilité. Quand ce signal n'est pas donné, les forces de réduction du risque (IT, juridique) ont toutes les incitations à bloquer tout ce qui pourrait poser problème. C'est structurellement rationnel pour chacun des acteurs individuellement. C'est collectivement paralysant¹.

Le paradoxe de l'adoption : 40% des salariés utilisent l'IA, 77% de l'usage API est de l'automatisation

L'Anthropic Economic Index de septembre 2025 pose un constat qui devrait alerter tout DSI. D'un côté, 40% des employés américains déclarent utiliser l'IA au travail — contre 20% deux ans plus tôt. De l'autre, côté API entreprise, 77% des usages professionnels impliquent des schémas d'automatisation, pas d'augmentation collaborative⁴.

Ce chiffre révèle un glissement silencieux. Les entreprises qui ont franchi le pas n'utilisent pas l'IA pour « aider » leurs développeurs à la marge. Elles l'utilisent pour déléguer des tâches entières. L'usage « directif » — où une tâche est entièrement confiée à l'agent — a, pour la première fois dans la période étudiée, dépassé l'usage augmentatif. La frontière entre l'assistance et l'autonomie est déjà franchie dans les équipes pionnières.

Mais le rapport identifie aussi un goulot d'étranglement critique qui freine ce passage à l'échelle : l'accès aux informations contextuelles appropriées. Les tâches complexes nécessitent des entrées longues, une modernisation des données, des investissements organisationnels significatifs. Ce n'est pas un obstacle technique — c'est un obstacle de gouvernance et d'architecture de l'information⁴.

Le « Context Gap » : le vrai obstacle que personne ne nomme

Il faut nommer ce problème correctement, parce que le nommer différemment conduit à des mauvaises solutions. Quand une équipe dit « notre pilote n'a pas donné les résultats escomptés », elle désigne souvent le modèle, l'outil ou le prompt. La réalité est presque toujours ailleurs : l'agent ne savait pas dans quel contexte il travaillait.

C'est ce que SFEIR désigne sous le concept de Context Engineering — l'art de nourrir les agents IA avec le bon environnement, au bon moment, de façon persistante. La différence entre un prompt isolé (interaction éphémère, mémoire zéro entre sessions) et un contexte ingénieré (architecture à trois niveaux Hot/Warm/Cold, mémoire cross-sessions, ROI composé) est la différence entre un stagiaire qui repart de zéro chaque matin et un collaborateur qui accumule de la connaissance. Le ROI d'un contexte bien architecturé n'est pas linéaire — il est composé : chaque session s'appuie sur la précédente, chaque décision documentée réduit les erreurs futures, chaque convention encodée évite une correction après coup.

Patrick Debois résume la pathologie en une formule : « Chaque session est un nouvel employé qui repart de zéro. » L'agent coding le plus puissant du marché produira des résultats décevants s'il ignore les conventions de votre codebase, vos règles de sécurité, l'historique des décisions architecturales, les tickets en cours, les standards de revue. Ce n'est pas un déficit du modèle — c'est un déficit de contexte. Et le corriger est un chantier organisationnel avant d'être un chantier technique.

La bonne nouvelle, c'est que ce chantier est abordable. Il commence par trois artefacts concrets : un fichier d'instructions persistant (ce que les outils comme Claude Code appellent CLAUDE.md), un registre des décisions architecturales à jour, et une convention de nommage des issues/tickets que les agents peuvent lire et interpréter. Ces trois éléments, mis en place dans les premières semaines, constituent la mémoire tiède de l'agent — le fondement sans lequel l'autonomie croissante ne produit que du bruit.

Augmenté d'abord, autonome ensuite : la progression qui évite le crash

L'erreur la plus fréquente n'est pas de ne pas oser — c'est d'osciller entre deux extrêmes : déployer un copilote sous-utilisé qui ne change rien, ou lancer directement des agents autonomes sans les garde-fous nécessaires. Les deux trajectoires produisent les mêmes 95% d'échec.

La doctrine AI for IT — la stratégie du 10x de SFEIR pose une progression claire : on ne vise pas des gains marginaux de productivité, on vise un facteur dix — mais ce facteur dix se construit par paliers. L'anti-pattern revendiqué est explicite : « Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement. » (Didier Girard, SFEIR) Ce n'est pas une provocation rhétorique — c'est une affirmation de destination. La question est comment on y arrive sans tout casser en chemin.

Le premier palier est l'augmentation : le développeur reste pilote, l'agent exécute sous supervision directe, les PRs sont revues systématiquement. Le bénéfice est immédiat mais modeste — un gain de vitesse de 30 à 50% sur les tâches répétitives. Le deuxième palier est l'autonomie supervisée : l'agent prend des initiatives, propose des implémentations complètes, le développeur bascule en rôle de reviewer et d'architecte. C'est là que le gain devient perceptible à l'échelle — les équipes qui ont franchi ce palier rapportent des multiplications par deux à trois de leur vélocité effective. Le troisième palier est l'autonomie en boucle : les agents tournent en continu sur des périmètres définis, les humains définissent les objectifs et arbitrent les décisions non résolues. C'est l'horizon vers lequel convergent les équipes les plus avancées.

Boris Cherny décrit sa propre trajectoire : les six premiers mois, 10% du code généré par l'IA, « à peine utilisable ». Puis l'inflexion de mai 2025. Aujourd'hui, 100% du code est généré par le modèle, avec plusieurs dizaines de PRs par jour et un record à 150 en une journée³. Ce n'est pas une trajectoire instantanée — c'est une montée en compétence progressive, sur un modèle qui s'améliorait en parallèle.

Pour les équipes qui démarrent en 2026, la progression est plus rapide — les modèles sont meilleurs, les outils plus matures, les patterns mieux documentés. Mais elle reste une progression. Vouloir sauter directement au stade terminal est le raccourci le plus sûr vers l'échec.

Risques et contre-effets : ce que les optimistes oublient de mentionner

L'adoption de l'agentic coding n'est pas sans risques — les ignorer serait exactement la technophilie béate que l'on reproche aux vendeurs d'IA.

La dette de contexte. Si vous déployez des agents sans investir dans le Context Engineering, vous créez une dette invisible. Les agents produisent du code syntaxiquement correct qui viole silencieusement vos conventions, vos contraintes de sécurité, votre cohérence architecturale. Le coût de correction est exponentiel à mesure que la codebase grandit.

La concentration des gains. L'Anthropic Economic Index le documente : les régions et organisations qui tirent le plus de valeur de l'IA sont celles qui partent déjà avec les meilleures infrastructures de données et les équipes les plus matures. L'IA est un amplificateur — elle amplifie aussi les dysfonctionnements⁴.

La dépendance au modèle sans montée en compétence. Cherny lui-même le nuance : « coding is solved » s'applique à son contexte — une codebase TypeScript/React de taille raisonnable, avec un modèle de pointe. Sur les grandes bases de code legacy, les langages rares, les systèmes embarqués, le modèle n'est pas encore là³. Et une équipe qui a délégué son expertise technique sans la développer en parallèle se retrouve dépendante sans recours.

Le risque de blocage organisationnel camouflé. Mollick le formule brutalement : les comités d'approbation ne sont pas irrationnels — ils sont rationnels dans leur propre référentiel. Si le dirigeant n'assume pas le risque, IT et juridique ont toutes les raisons de bloquer. Lancer un projet d'agentic coding sans ce signal politique clair condamne le projet à mourir en pilote¹.

Cinq leviers pour lancer sans se rater

Ces cinq leviers ne sont pas des étapes séquentielles — certains doivent être engagés en parallèle. Mais aucun n'est optionnel.

1. Obtenir le signal politique en premier. Avant tout outil, avant tout pilote : le ou la dirigeant·e responsable doit explicitement assumer le risque et le déclarer en interne. Sans ce signal, IT et juridique optimisent correctement pour le zéro risque — et bloquent tout. Ce n'est pas un problème de procédure, c'est une question de leadership. Chercher à contourner ce point en montant un pilote en catimini est une voie vers le sabordage.

2. Commencer par un périmètre à contexte riche et risque faible. Le périmètre idéal pour les premières semaines : une nouvelle codebase ou un module isolé, avec une équipe de deux à trois développeurs motivés, sur un langage bien couvert par les modèles (TypeScript, Python, Java récent). Ce n'est pas un pilote de démonstration — c'est une mise en production réelle, sur une surface maîtrisable. Les règles du jeu sont documentées dès le départ dans un CLAUDE.md ou équivalent : conventions de code, standards de sécurité, contraintes d'architecture.

3. Investir dans le Context Engineering avant d'accélérer. Avant de pousser sur la vitesse, l'équipe doit construire son architecture de contexte : mémoire chaude (instructions de session, fichier CLAUDE.md ou équivalent), mémoire tiède (règles et conventions persistantes, ADR, runbooks), mémoire froide (documentation technique de référence, historique des incidents, schémas de données). Ce travail n'est pas glamour. Il conditionne pourtant tout le reste. Un agent sans contexte riche produit du code volumineusement médiocre — syntaxiquement correct, sémantiquement hors-sol. Et le ratio d'un investissement de deux jours dans la documentation de contexte se mesure en semaines de rework évité.

4. Mesurer les bons indicateurs dès le premier sprint. Les ETP et le temps passé sont des indicateurs obsolètes dès lors que les agents génèrent le code. Les indicateurs pertinents : nombre de PRs mergées par semaine, délai moyen de cycle (du ticket au merge), taux de rework sur le code généré, couverture de tests. Ces métriques permettent d'objectiver la progression et de la rendre lisible pour la direction — condition nécessaire à l'obtention des ressources pour la suite.

5. Planifier la montée en autonomie, pas l'autonomie immédiate. Dès le lancement, définir les trois stades (augmentation → autonomie supervisée → autonomie en boucle) et les critères de passage de l'un à l'autre. Cette feuille de route n'est pas une contrainte bureaucratique — c'est la protection contre la tentation de sauter des étapes sous pression de résultats. La SFEIR Software Factory industrialise précisément ce passage : chaque palier est une transformation du SDLC, pas seulement un changement d'outil.

Ce que nous observons sur le terrain

Les organisations qui avancent le plus vite ne sont pas celles qui ont les modèles les plus récents ni les budgets les plus importants. Ce sont celles où le signal politique est clair, le périmètre de départ bien borné, et le Context Engineering traité comme un chantier de premier ordre — pas comme un à-côté qu'on gérera plus tard.

Ce que SFEIR constate dans ses accompagnements, de Société Générale à Decathlon en passant par les DSI industrielles qui se posent la question depuis dix-huit mois : le premier obstacle est presque toujours interne. Les équipes de développeurs ne demandent pas à être convaincues — elles demandent l'autorisation et le cadre. Débloquer ce cadre, c'est la contribution décisive que la direction peut apporter.

Boris Cherny résume l'avantage concurrentiel d'Anthropic en une formule qui vaut bien au-delà d'Anthropic : « L'endroit où nous avons de l'avance, ce n'est pas la technologie — c'est la structure organisationnelle et les processus. »³ Le même modèle est disponible pour tout le monde. La différence se joue dans la capacité à l'intégrer dans le flux de travail réel.

Conclusion : la presse de Gutenberg n'a pas attendu que tout le monde soit prêt

Cherny utilise l'analogie de la presse de Gutenberg pour décrire ce qui se passe dans le software : en 1400, 10% de la population européenne savait lire. Cinquante ans après l'invention, plus de littérature avait été publiée en Europe que dans les mille ans précédents. Le livre avait perdu 100 fois son coût. Quelques siècles plus tard, 70% de la population mondiale savait lire³.

La démocratisation du software suit la même logique — plus vite. Les entreprises qui l'ont compris ne se posent plus la question de savoir si elles vont adopter l'agentic coding. Elles se posent la question de savoir quelle proportion de leur pipeline sera gérée par des agents d'ici dix-huit mois.

La question que Mollick pose à ses interlocuteurs n'est pas rhétorique : pendant que votre comité approuve les cas d'usage un par un, votre concurrent direct dans la même industrie a dix-huit mois d'avance. Ce fossé ne se comble pas avec un pilote de plus. Il se comble avec un choix de leadership, suivi d'une méthode. C'est précisément la bascule décrite dans le pilier « Coding is solved ».

Points clés

• Le goulot n'est pas le modèle, c'est le leadership : selon Ethan Mollick, le facteur décisif dans l'adoption de l'agentic coding est la volonté d'un dirigeant d'assumer le risque — sans ce signal politique clair, les forces de réduction du risque (IT, juridique) bloquent structurellement toute avancée.¹
• Le Context Gap est le vrai obstacle technique : l'Anthropic Economic Index identifie l'accès aux informations contextuelles appropriées comme le principal goulot d'étranglement du déploiement sophistiqué en entreprise — investir dans le Context Engineering avant d'accélérer conditionne tous les résultats.⁴
• Augmenté d'abord, autonome ensuite : la progression par paliers (augmentation → autonomie supervisée → autonomie en boucle) est la seule trajectoire qui évite les 95% de pilotes sans ROI — sauter des étapes sous pression est le chemin le plus sûr vers l'échec.
• Mesurer les bons indicateurs dès le départ : les ETP et le temps passé sont obsolètes dans un SDLC agentique — PRs mergées par semaine, délai de cycle et taux de rework sont les métriques qui rendent la progression visible et défendable en COMEX.
• L'avantage compétitif est organisationnel, pas technologique : les mêmes modèles sont accessibles à toutes les organisations — la différence entre celles qui créent de la valeur et celles qui accumulent des pilotes sans suite tient à la structure organisationnelle et aux processus, pas à l'accès aux outils.

Sources

1. Ethan Mollick (Wharton) — linkedin.com, 5 mars 2026.
2. MIT NANDA, rapport sur les pilotes IA — legal.io, 23 août 2025.
3. Boris Cherny (Anthropic), intervention Sequoia AI Ascent — youtube.com, 5 mai 2026.
4. Anthropic, Anthropic Economic Index — September 2025 Report — anthropic.com, 15 septembre 2025.