GitHub Copilot est dans 90 % des entreprises Fortune 100. Une étude commanditée par GitHub a révélé que les développeurs complètent les tâches 55 % plus vite avec l'assistance IA. Selon tous les indicateurs de vélocité, l'industrie a fait un véritable bond en avant. Mais voici le problème : les taux de réussite des projets n'ont pas bougé. Le retravail n'a pas diminué. Et le nombre de fonctionnalités qui se déploient, qui sont utilisées et qui résolvent réellement le problème que les parties prenantes envisageaient reste obstinément, frustramment le même.
Je sais pourquoi. Et c'est devenu le défi déterminant de 2026.
Qu'est-ce que la gueule de bois Copilot ?
La gueule de bois Copilot n'est pas un bogue dans l'IA. C'est une caractéristique de la manière dont nous avons choisi de le déployer. Nous avons optimisé l'accélération sans aborder l'alignement. Nous avons rendu possible de coder plus vite que de nous assurer que nous codons la bonne chose.
Lorsqu'un développeur s'assoit avec un requis vague et que Copilot propose des complétions, ces complétions ont l'air soignées. Intelligentes. Prêtes à être déployées. Le développeur les code en heures. L'équipe les déploie en jours. Et deux semaines plus tard, l'intervenant dit : « Ce n'est pas ce que je voulais dire. »
Le code a été écrit correctement. La spécification a été construite correctement. Le problème est que la spécification elle-même était incomplète, ambiguë ou basée sur des hypothèses non examinées. Et au moment où quelqu'un le réalise, 40 à 50 pour cent de l'effort d'un sprint a déjà été investi dans la construction de la mauvaise chose.
Pourquoi coder plus vite n'améliore-t-il pas les résultats des projets ?
C'est l'écart qui compte : l'écart entre la vélocité et l'alignement.
La vélocité est la vitesse à laquelle un développeur peut transformer une spécification en code. C'est ce que Copilot optimise. L'alignement, c'est si l'équipe, les parties prenantes, les responsables techniques et les utilisateurs comprennent tous ce qu'ils construisent et pourquoi. C'est ce que personne n'a optimisé.
La gueule de bois Copilot est l'accélération sans alignement. Construire la mauvaise chose, juste plus vite que jamais.
Voici ce qui se passe en pratique : Un responsable produit écrit un requis. Un développeur l'interprète. Un intervenant avait une troisième signification à l'esprit. Personne ne détecte ce désalignement jusqu'à ce que le code soit écrit, déployé et ne parvienne pas à fournir de valeur. À ce moment-là, corriger l'erreur de requis coûte 29 fois plus cher que si elle avait été détectée lors de la planification. Le sondage Stack Overflow 2024 auprès des développeurs a révélé que les développeurs passent plus de temps à comprendre les requis et à déboguer du code mal aligné qu'à écrire de nouvelles fonctionnalités, pourtant les outils IA restent presque exclusivement concentrés sur l'étape de génération de code.
Ce n'est pas un risque marginal. C'est le poids accumulé de chaque sprint qui a déraillé parce que des hypothèses n'ont pas été validées. Chaque fonctionnalité qui s'est déployée et n'a pas résolu ce qu'elle était censée résoudre. Chaque projet où l'équipe a livré la spécification parfaitement, mais la spécification elle-même était mauvaise. C'est le problème invisible qui se cache au grand jour dans toute l'industrie.
Quelle est la différence entre l'IA brouillon d'abord et l'IA décision d'abord ?
La plupart des outils IA aujourd'hui - y compris GitHub Copilot et ChatGPT - sont ce que j'appelle brouillon d'abord. Vous leur donnez un prompt, ils génèrent un brouillon complet. Il a l'air professionnel. Il sonne avec autorité. Mais c'est une seule perspective, d'un seul angle, sans aucune validation structurée derrière.
Le danger des outils brouillon d'abord est qu'ils résolvent le problème de la confiance. Un brouillon complet et poli crée l'illusion d'alignement. L'équipe le regarde et approuve. Personne ne pose les questions difficiles parce que les questions difficiles ont déjà été pré-répondues par une IA qui n'a aucun intérêt à ce que ces réponses soient correctes.
Ce qui mène réellement au succès du projet, c'est la pensée « décision d'abord ». Au lieu de générer un document, structurez les décisions qui doivent être prises : Qui sont les utilisateurs réels ? Quelles contraintes existent ? Quels compromis faisons-nous ? Sommes-nous tous d'accord sur ces compromis ? Ce n'est que lorsque ces décisions sont prises - et validées par l'équipe - que le code devrait même être envisagé.
La différence est profonde. Avec brouillon d'abord, vous obtenez la vitesse qui se déguise en complétude. Avec décision d'abord, vous obtenez la clarté. Et la clarté est ce qui détermine réellement le succès d'un projet.
Qu'est-ce que la gouvernance pré-code et pourquoi est-elle importante ?
Entre « nous avons une idée » et « nous sommes prêts à coder » il doit y avoir une gouvernance. Pas au sens bureaucratique. Au sens où : Avons-nous posé les bonnes questions ? Avons-nous des réponses alignées ? Suivons-nous les compromis que nous faisons et qui était d'accord ?
J'appelle cela la gouvernance pré-code, et elle est pratiquement entièrement absente du développement logiciel moderne. Les équipes passent d'une idée vague à un code détaillé en heures. Le résultat est un code qui est rapide et mauvais.
La gouvernance pré-code ne ralentit pas la livraison. Elle l'accélère. Parce qu'au moment où vous avez la clarté sur ce que vous construisez et pourquoi, vous arrêtez de construire les mauvaises choses. Vous éliminez 40 à 50 pour cent du retravail qui aurait eu lieu en aval. Vous livrez des fonctionnalités qui se déploient réellement, parce qu'elles résolvent le vrai problème. Comme nous l'avons exploré dans comprimer six semaines de requis en une journée, le temps épargné en aval dépasse largement le temps investi en amont.
Une session de gouvernance pré-code prend typiquement une journée de travail. L'équipe aborde quatre questions critiques avant l'écriture de toute ligne de code :
Qui exactement sont les utilisateurs, et dans quel flux de travail nous insérons-nous ? Pas un document de persona. Une description concrète de la personne qui utilisera cette fonctionnalité, ce qu'elle fait avant et après, et quel résultat elle attend.
Quelles sont les contraintes techniques non négociables ? Cibles de latence, points d'intégration, limites de volume de données, périmètres de sécurité. Ces contraintes façonnent l'architecture. Les découvrir après le début du codage, c'est ainsi que les équipes finissent par tout reconstruire de zéro.
Que ne construisons-nous explicitement PAS dans cette version ? Le périmètre est défini autant par ce que vous excluez que par ce que vous incluez. Rendre ces exclusions explicites prévient la dérive du périmètre et les ajouts de type « tant qu'on y est » qui font dérailler les échéanciers.
Quels compromis faisons-nous, et qui les a approuvés ? Chaque projet implique des compromis entre rapidité, qualité, coût et périmètre. Quand ces compromis sont implicites, ils deviennent des surprises. Quand ils sont explicites et signés, ils deviennent des décisions. Le Standish Group CHAOS Report constate systématiquement que les projets avec des requis clairs et l'implication des parties prenantes ont trois fois le taux de réussite de ceux qui en sont dépourvus.
En octobre 2015, j'ai commencé un nouveau rôle chez Technology Evaluation Centers, chargé de diriger une transformation numérique qui touchait les ventes, le juridique, les opérations et le support client. L'équipe utilisait Microsoft XRM, un outil no-code avec lequel ils avaient essayé de construire tous leurs flux de travail eux-mêmes. Ils pensaient pouvoir tout automatiser - lier les appels de vente à l'inventaire, les approbations juridiques, toute la chaîne. Ce qu'ils avaient réellement construit, c'était un bazooka pour tuer un moustique : une bête surcompliquée que personne ne comprenait vraiment et qui ne fonctionnait pas correctement.
Alors mon architecte Alexei Goldman et moi nous sommes assis avec chaque intervenant et avons dit : « Ne commençons pas par comment vous voulez que ce soit fait. Commençons par ce qui vous dérange. » Nous les avons fait reculer du langage technique pour simplement nous dire leurs irritants, leurs résultats idéaux, et où ils étaient prêts à faire des compromis.
Cette conversation humaine d'abord nous a épargné une tonne de maux de tête. Oui, il a fallu trois mois pour obtenir un dossier solide pour les développeurs - typique avec les délais d'alignement des calendriers et les allers-retours de questions de suivi. Mais nous avons fini avec un système réellement maintenable et compréhensible pour tout le monde. La grande leçon : avant de plonger dans la construction, assurez-vous de parler le même langage humain d'abord. L'alignement, c'est tout.
Comment adapter votre stratégie de codage IA avant qu'il ne soit trop tard ?
Si vous utilisez Copilot (et 90 % des Fortune 100 le font), vous avez un choix. Vous pouvez l'utiliser comme la plupart des équipes le font : comme un moteur de génération de code qui permet aux développeurs de coder plus vite sans confirmer qu'ils codent la bonne chose. Ou vous pouvez le traiter comme faisant partie d'une approche plus large où le travail difficile d'alignement se produit avant le travail de code.
Voici quatre étapes concrètes pour échapper à la gueule de bois Copilot :
1. Investissez dans la clarté des requis avant le codage commence. Pas des semaines de réunions. Une session structurée où l'équipe s'aligne sur les besoins des utilisateurs, les contraintes techniques, les requis de sécurité et les compromis. Rendez les décisions explicites. Suivez-les. Obtenez un accord.
2. Faites des décisions un artéfact de première classe. Pas des documents. Des décisions. Pour qui construisons-nous ? Qu'est-ce que nous construisons ? Qu'est-ce que nous ne construisons pas, et pourquoi ? Quels compromis avons-nous faits ? Écrivez-les. Référencez-les lors de l'examen du code. Utilisez-les pour détecter la dérive.
3. Impliquez les gens qui utilisent réellement le logiciel. Pas à la démo. À la phase des requis. Intégrez-vous dans leur flux de travail comme je l'ai fait dans ce centre de dépêche. Comprenez ce qu'ils ont réellement besoin, pas ce qu'ils pensent pouvoir demander.
4. Traitez la vélocité du code comme un indicateur retardé. C'est une information utile, mais ce n'est pas une mesure du progrès. Mesurez l'alignement à la place. Les décisions sont-elles claires ? Les parties prenantes disent-elles « oui, exactement » lors de la conception, pas « ce n'est pas ce que je voulais dire » lors de l'assurance qualité ?
La véritable opportunité Copilot
Nous avons passé deux ans à utiliser l'IA pour accélérer la phase d'exécution de la livraison logicielle. La véritable percée viendra quand nous pointerons cette même capacité vers la phase de réflexion. Quand nous rendrons plus facile de poser les bonnes questions avant le code, plutôt que de moins chère de corriger les réponses après.
Les équipes qui comprennent cela en premier auront un avantage structurel qui se compose à chaque projet. Elles se déploieront plus vite parce qu'elles passent moins de temps à construire la mauvaise chose. C'est pourquoi la plus grande percée en livraison logicielle n'est pas un code plus rapide, c'est une réflexion plus claire avant le code.
Questions fréquentes
