Quand l’IA entre dans le cycle dev sans cadre : le coût caché de l’adoption opportuniste

L’IA générative s’est imposée dans toutes les équipes de développement. Pourtant, les gains promis tardent à venir. Dans la quasi-totalité des cas, le problème n’est pas l’outil. C’est l’absence de cadre.

L’IA est partout. Les gains, beaucoup moins.

En deux ans, l’IA générative est entrée dans toutes les équipes dev. Même les plus prudentes l’ont adoptée. Chacun a ses outils (ChatGPT, Claude, Copilot, Cursor) et son propre usage.

Et pourtant, quand on regarde les indicateurs qui comptent vraiment pour une direction technique (vélocité réelle, qualité du code livré, prévisibilité des cycles), le bilan est souvent en demi-teinte. On produit plus de code, plus vite. Mais on ne livre pas forcément mieux, ni plus vite là où ça compte.

Il faut ici distinguer deux choses que l’on confond trop souvent. La productivité apparente, c’est-à-dire le nombre de lignes générées et la vitesse à laquelle une première version sort, explose avec l’IA. La productivité réelle, soit le temps qu’il faut pour qu’une fonctionnalité atteigne la production sans régression et reste maintenable, bouge beaucoup moins. Parfois, elle recule. Un assistant qui génère vite du code moyen ne fait souvent que déplacer l’effort : ce qu’on gagne à l’écriture, on le repaie en revue, en correction et en dette. Tant qu’on mesure le volume plutôt que la valeur livrée, on se félicite d’un gain qui n’existe pas.

Cet écart entre la promesse et le terrain n’est pas une fatalité. Il a une cause, et elle est presque toujours la même.

Le vrai problème n’est pas l’IA, c’est l’absence de cadre

Quand on creuse, les difficultés se ressemblent d’une équipe à l’autre. Six symptômes reviennent :

• Une productivité décevante, loin de ce qui était attendu.
• Une qualité qui se dégrade: plus de code généré, donc plus de dette technique et de régressions à absorber en aval.
• Une perte de visibilité: il devient difficile de tracer ce que l’IA a produit, et pourquoi.
• Une dérive des coûts: consommation de tokens et licences qui s’accumulent sans être pilotées.
• Une question de propriété intellectuelle: du code confié à des serveurs tiers, hors du périmètre maîtrisé de l’entreprise.
• Une surface de sécurité élargie, avec des contrôles qui n’ont pas été repensés.

À cette liste s’ajoute un angle mort que l’on évoque rarement : l’humain. Dans une même équipe coexistent souvent trois postures face à l’IA : l’appréhension (« vais-je être remplacé ? »), l’hostilité (l’outil perçu comme une dégradation du métier) et la désorientation (« quelle compétence dois-je développer pour en tirer parti ? »). Tant que ces questions restent en suspens, l’adoption reste superficielle.

Tous ces symptômes ont une racine commune : un usage opportuniste, non cadré. Chacun bricole dans son coin, avec des prompts jetables que personne ne partage et que rien ne capitalise. C’est précisément ce qui plafonne, pas l’IA elle-même.

Le coût caché de l’adoption opportuniste

Ces symptômes ont un point commun : ils ne se voient pas immédiatement. C’est ce qui rend l’adoption opportuniste si trompeuse : elle donne le sentiment d’avancer pendant que la facture s’accumule ailleurs.

Le premier coût caché est la dette technique différée. Du code produit vite et sans cadre, c’est du code qu’il faudra comprendre, tester et reprendre plus tard, souvent par quelqu’un d’autre que celui qui l’a généré.

Le deuxième est le temps de revue. Plus l’IA produit, plus les pull requests s’allongent, et plus la charge se reporte sur les développeurs expérimentés, qui deviennent le goulot d’étranglement de toute l’équipe.

Le troisième est la perte de connaissance. Quand personne ne sait précisément ce que l’IA a écrit ni pourquoi, la maîtrise du code s’érode. La reproductibilité disparaît : on ne sait plus régénérer ni faire évoluer proprement ce qui a été produit.

Le dernier est humain. Une équipe qui subit l’outil au lieu de le piloter se démobilise. Et une démobilisation, dans une équipe technique, finit toujours par coûter cher, en qualité comme en fidélisation.

Aucun de ces coûts n’apparaît dans un tableau de bord le premier mois. Tous se paient sur la durée. C’est précisément pour cela qu’on parle de coût caché : il est bien réel, mais il ne se manifeste que lorsqu’il est déjà difficile de revenir en arrière.

Le tournant : la spécification comme artefact central

La réponse n’est pas « plus d’IA ». C’est un cadre. Et ce cadre porte un nom : le Spec-Driven Development (SDD).

Le principe est simple à énoncer. La spécification redevient l’artefact central du cycle de développement. Le Product Owner se réapproprie l’amont : il écrit et versionne une intention explicite, qui devient la source de vérité. L’IA, quant à elle, ne s’exécute plus à l’aveugle sur un prompt improvisé : elle produit à partir de cette spécification, dans un cadre contrôlable et reproductible. Le code, les tests et les pull requests découlent de la spec, en aval.

Pourquoi la spécification, et pas autre chose ? Parce qu’elle est le seul artefact à la fois lisible par un humain et exploitable par une machine. Un prompt jetable se perd dès qu’il a servi. Le code, lui, dit le « comment » mais rarement le « pourquoi ». La spécification capture l’intention, c’est-à-dire ce que l’on veut obtenir et sous quelles contraintes, dans une forme que le métier peut valider et que l’IA peut exécuter. C’est le point de rencontre entre deux mondes qui, jusqu’ici, se parlaient mal. À l’opposé du « vibe coding », où l’on demande à l’IA de deviner et où l’on accepte ce qui sort, le SDD repose sur une intention écrite, discutée et versionnée.

Ce déplacement change la nature même de l’usage de l’IA. On passe d’un assistant qui improvise à un exécutant qui réalise une intention cadrée. Trois bénéfices en découlent directement :

• Contrôlable: on sait ce que l’IA doit produire, et on peut le vérifier au regard de la spec.
• Reproductible: une même spécification mène au même cadre d’exécution, d’un développeur à l’autre.
• Aligné: le métier et la technique travaillent enfin sur le même socle, au lieu de se renvoyer la balle.

C’est là que se trouve le vrai gain de l’IA dans le cycle de développement : ce que nous appelons le Flow AI, l’IA appliquée au processus de développement, par opposition à l’IA embarquée dans les produits.

Ce que change concrètement le Spec-Driven Development

Passer d’un usage basique à un usage industrialisé ne tient pas à un outil miracle. Cela suppose quelques briques structurantes : un framework unifié, partagé par toute l’équipe plutôt que dix pratiques individuelles ; un guide interne qui décide quel modèle utiliser pour quel besoin, au lieu de tout faire tourner sur le modèle le plus puissant et le plus cher ; des agents structurés et réutilisables ; et une intégration qui fait circuler la spécification de l’outil métier (Jira) jusqu’au dépôt de code (GitHub).

Mais ce passage à l’échelle ne s’improvise pas, et j’insiste sur ce point. C’est là que beaucoup d’équipes trébuchent.

Sécurité, propriété intellectuelle et gouvernance

Industrialiser l’IA dans le cycle de développement, c’est aussi reprendre le contrôle sur des questions qu’un usage opportuniste laisse en suspens. Où part le code envoyé à un modèle ? Quelles données quittent votre périmètre ? Qui peut tracer ce qui a été produit, et le justifier en cas d’audit ?

Tant que chaque développeur utilise l’outil de son choix, ces réponses varient d’un poste à l’autre, ce qui, pour une direction technique, est intenable. Un cadre commun permet au contraire de trancher une fois pour toutes : quels modèles sont autorisés, sur quelles données, avec quelle traçabilité, et sous quelles contraintes de souveraineté ou de conformité. La spécification, parce qu’elle documente l’intention, devient aussi une trace : on sait ce qui a été demandé, et pourquoi.

La sécurité cesse alors d’être un frein opposé à l’IA pour devenir une condition de son passage à l’échelle.

Mesurer l’impact, sans se raconter d’histoires

On ne pilote bien que ce que l’on mesure, encore faut-il mesurer la bonne chose. La tentation, avec l’IA, est de se rassurer avec des indicateurs flatteurs : le nombre de suggestions acceptées, les lignes générées, le taux d’adoption de l’outil. Aucun ne dit si l’on livre mieux.

Les indicateurs qui comptent sont ceux qui rapprochent l’effort de la valeur : le délai entre une demande et sa mise en production, la stabilité de ce qui est livré (régressions, incidents) et le coût réel d’une fonctionnalité, IA comprise. Ce sont des mesures exigeantes, parfois inconfortables, mais ce sont les seules qui permettent de savoir si l’industrialisation tient ses promesses.

Les pièges qui guettent

Pour avoir mis cette approche en œuvre sur des projets réels, j’en retiens quelques écueils récurrents :

• Le modèle le plus puissant partout. Utiliser un modèle premium pour chaque tâche fait exploser la facture pour un gain souvent marginal. Le bon réflexe est de calibrer le modèle au besoin.
• L’automatisation aveugle. Tout automatiser sans conserver de points de contrôle humains sur les étapes clés revient à transférer le risque, pas à le réduire.
• L’over-engineering du kit. À force de structurer, on passe de trois agents bien pensés à quatorze agents ingérables que plus personne n’utilise.
• La consommation de tokens oubliée. Plus on structure, plus l’IA recharge le contexte du projet à chaque sollicitation, et consomme donc avant même de répondre. Un coût invisible qui se chiffre vite.

Aucun de ces pièges n’est rédhibitoire. Mais les éviter demande une méthode, pas de la bonne volonté.

Par où commencer : les bonnes questions à se poser

Avant de parler outils ou agents, quelques questions suffisent à situer une équipe. Disposez-vous d’un cadre commun, ou de dix pratiques individuelles juxtaposées ? Savez-vous, aujourd’hui, tracer ce que l’IA a produit dans votre code ? Le métier est-il associé en amont, ou découvre-t-il le résultat en aval ? Et mesurez-vous autre chose que le volume produit ?

Si la réponse à plusieurs de ces questions est « non », le problème n’est pas votre niveau d’adoption de l’IA : il vient de l’absence de cadre. La bonne nouvelle, c’est que ce cadre se construit progressivement : on commence par un périmètre limité, une équipe pilote, une spécification bien tenue, avant d’étendre. L’industrialisation n’est pas un grand soir, c’est une discipline qui s’installe.

Méthode, mesure, sécurité : on en parle en détail le 24 juin

Cet article pose le cadre. La mise en œuvre concrète mérite mieux qu’un texte.

Le mercredi 24 juin à 11h, nous animons un webinar où nous allons plus loin, sur les trois dimensions qui font la différence : la méthode (comment construire un kit SDD qui tient la route), la mesure (comment objectiver les gains, sans se raconter d’histoires) et la sécurité (IP, données, contrôles). Le tout avec une démonstration en direct, d’une spécification à une pull request, et un retour d’expérience sur un projet de migration réel.

Format : 45 minutes, gratuit. Avec Pascal Rellier (CEO), Yasser Jebbari (Practice Manager IA) et moi-même.

Réserver ma place

Mahdi El Jaouhari, CTO de Go&Dev.