Construire vite ne suffit plus : trois garde-fous pour que l'IA ne noie pas vos équipes sous la dette technique

La vitesse sans intention, c'est de la dette déguisée en productivité

Un prototype généré en quelques promptsConsigne / contexte fourni au modèle pour orienter sa génération (system, user, exemples, outils). a l'air prêt pour la prod. Il ne l'est presque jamais. Jake Albaugh, Developer Advocate chez Figma, pose le problème sans détour lors de sa présentation à Config 2026 (25 juin) : l'IA accélère l'exécution, pas la clarté. Le polish visuel d'un output LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. nous trompe parce que, avant l'IA, ce niveau de finition reflétait des décisions durement acquises — contraintes système, arbitrages techniques, choix de design. Aujourd'hui, le modèle comble les trous à notre place, et le résultat « s'effondre en interne ».

Albaugh emprunte à Shaw et Nave (papier académique « Thinking—Fast, Slow, and Artificial ») le concept de reddition cognitive (cognitive surrender) : le moment où l'on accepte la sortie de l'IA sans examen, en substituant le jugement du modèle au sien. Il ne s'agit pas d'un risque théorique — Albaugh reconnaît le faire lui-même régulièrement. Sa réponse : un « consideration imperative », c'est-à-dire le choix délibéré de rester avec le problème assez longtemps pour savoir ce qui vaut la peine d'être construit, avant de prompter quoi que ce soit.

Pour les leads techniques et les agences, la question du lundi matin est simple : qu'est-ce qu'on délègue à l'IA, et qu'est-ce qu'on garde sous contrôle humain ? La vitesse n'est pas le problème. La vitesse sans intention, si.

Trois couches de contexte pour que les agents arrêtent de deviner

Un document Google signé Addy Osmani, Shubham Saboo et Sokratis Kartakis (« The New SDLC With Vibe Coding », publié sur Kaggle et le blog d'Osmani en mai 2026) décrit comment le vibe coding à faible effort génère de la dette technique. Leur proposition repose sur ce qu'ils appellent l'agentic engineering : le rôle du développeur passe de l'écriture de code à l'expression d'intention, l'IA se chargeant de la traduction en logiciel.

Concrètement, le document identifie trois types de couches à mettre en place :

1. Des couches déterministes — tests, type checks, validation — qui s'exécutent de manière identique à chaque fois et rattrapent ce que le modèle rate.
2. Du contexte à haute valeur — specs, composants documentés — pour que l'agent travaille à partir de votre intention, pas de la sienne.
3. Des interfaces claires, pour que l'agent sache comment les pièces s'articulent au lieu de deviner.

C'est du travail en amont. Mais c'est exactement le type d'investissement qui rend le logiciel maintenable ensuite. Et c'est transposable côté design : un design system solide codifie des décisions, donne aux agents un vocabulaire précis et des garde-fous. Résultat selon Albaugh : des outputs cohérents, du code plus léger, moins de dette.

Le coût du vibe coding sans ces garde-fous ? Selon le document Google, 3 à 10 fois plus cher par feature. Et l'adoption est déjà massive : 85% des développeurs professionnels utilisent des agents IA.

Code Connect et MCP : donner aux agents le vrai code, pas des pixels

L'un des exemples concrets cités par Albaugh est Code Connect dans le MCP Figma. Quand un agent passe du design au code, il lui manque le contexte des composants de production. Code Connect lui fournit le code réel — props et variants inclus — au lieu de le laisser reconstruire les composants à partir de pixels.

C'est un cas d'école du deuxième levier (contexte à haute valeur) : plutôt que de corriger en aval ce que l'agent a mal deviné, on lui donne la bonne source en amont. Pour les équipes qui maintiennent un design system, c'est un point d'intégration direct entre la source de vérité design et le workflow de génération de code.

Nous avions déjà couvert le sujet dans notre article sur Code Connect MCP, Figma tokens et qualité de code — le mécanisme reste le même, mais la présentation d'Albaugh le replace dans un cadre plus large sur la discipline de production.

Le piège de la moyenne : quand « bon » ne distingue plus rien

Le dernier point d'Albaugh est moins technique mais tout aussi concret. Les modèles sont entraînés sur des volumes massifs de données existantes. Ils connaissent chaque tendance, chaque pattern, et convergent vers la moyenne de ce qui existe déjà — ce qui est « in distribution » en termes de machine learning.

Demandez un logo : vous obtenez une marque géométrique avec un dégradé. Un pitch deck : la même police sans-serif que tout le monde. Un composant React : une card aux coins arrondis déjà vue partout. Rien de faux, presque tout est adéquat — et c'est précisément le problème. Accepter ces outputs assez souvent, et le jugement se rétrécit. On passe de « que devrait être ce produit ? » à « lequel de ces résultats est le moins mauvais ? ».

À mesure que l'IA s'améliore, chacun peut prompter quelque chose de meilleur qu'il y a un an — mais c'est toujours banal comparé à tout ce qui est généré autour. Le « bon » est un seuil que n'importe qui franchit désormais. Sans point de vue propre sur ce qu'on veut construire, c'est le modèle qui décide.

Ce que l'essai ne dit pas

La présentation d'Albaugh à Config 2026 est un essai d'opinion, pas une étude de terrain. Quelques questions restent ouvertes :

• Aucune donnée chiffrée sur la dette technique n'est avancée par Albaugh — ni volume de code churn, ni coût de maintenance. Le lien entre vibe coding et dette est posé comme évident, pas mesuré. Le white paper Google quantifie le coût (3-10x) et l'adoption (85%), mais Albaugh ne fournit aucune métrique propre.
• Le white paper Google est cité mais pas disséqué : quels résultats concrets les auteurs ont-ils observés en appliquant leurs couches déterministes ? La présentation d'Albaugh n'en dit rien.
• Code Connect est présenté comme solution de contexte, mais sans benchmarkJeu de référence public ou interne pour comparer des modèles (MMLU, HumanEval, etc.) — à lire avec prudence hors domaine. comparatif (avec/sans Code Connect, quel écart de qualité sur le code généré ?).
• La convergence vers la moyenne est décrite qualitativement. Existe-t-il des mesures de diversité des outputs sur des tâches de design ou de code ? La présentation ne renvoie vers aucune.

Ces absences ne disqualifient pas l'argument — elles invitent à le tester sur vos propres projets avant de l'adopter comme cadre.