Onze jours. L'automne dernier, on regardait une équipe de huit devs livrer une fonctionnalité en onze jours, alors qu'il y a deux ans, le même genre de feature leur aurait pris six semaines facile. Copilot a écrit peut-être 40 % du code. Les pull requests étaient propres. Le pipeline CI restait vert. Tout le monde se tapait dans le dos au standup du vendredi. Et puis le client a regardé la démo et a dit cinq mots : « C'est pas ça que j'ai demandé. »
Cinq mots. Huit personnes. Onze jours de travail à la poubelle. Et ce qui m'a frappé, c'est que l'équipe avait pas tort : elle avait suivi la spec à la lettre, sauf que c'est la spec elle-même qui était le problème, et Copilot avait rendu possible d'exécuter cette spec brisée plus vite que quiconque pouvait attraper l'erreur.
C'est ça, la gueule de bois Copilot. On la voit partout. Les chiffres confirment ce qu'on observe sur le terrain depuis un an : 90 % des Fortune 100 utilisent GitHub Copilot, les développeurs complètent les tâches 55 % plus vite avec l'assistance IA, et pourtant les taux de réussite des projets ont pas bougé. Pas d'un pouce. Zéro.
Qu'est-ce que la gueule de bois Copilot ?
On pensait que le problème, c'était la communication. Meilleures user stories. Critères d'acceptation plus détaillés. Boucles de feedback plus serrées. On avait partiellement raison, mais en fait c'est pas mal plus profond que ça.
Pas un bogue. La gueule de bois Copilot, c'est pas un problème technique dans l'IA, c'est une conséquence directe de comment on a choisi de la déployer. On a optimisé l'accélération sans jamais s'attaquer à l'alignement, on a rendu possible d'écrire du code plus vite qu'on peut confirmer qu'on écrit le bon code, et cet écart entre la vélocité et la justesse, c'est exactement là que les projets vont mourir.
Le pattern est toujours le même. Un dev ouvre son IDE à Boucherville un lundi matin avec un requis vague reçu sur Slack vendredi soir à 17h43. Copilot propose des complétions qui ont l'air soignées, intelligentes, prêtes pour la production. Quelques heures plus tard, le code est écrit. Déployé en quelques jours. Et deux semaines plus tard, l'intervenant plisse les yeux devant l'écran et lâche : « C'est pas ce que je voulais dire. » Le code était correct. La spec était suivie à la lettre. Mais la spec elle-même ? Incomplète. Ambiguë. Bâtie sur des hypothèses que personne avait examinées. Et rendu là, peut-être 40 à 50 pour cent de l'effort du sprint a déjà été englouti dans la construction de la mauvaise chose. Perdu.
Pourquoi coder plus vite n'améliore-t-il pas les résultats des projets ?
Vingt-cinq ans. Ça fait 25 ans que je gère des équipes de développement, et l'écart qui tue vraiment les projets a pas changé : la vélocité versus l'alignement. La vélocité, c'est la vitesse à laquelle un dev transforme une spec en code, et Copilot est spectaculaire là-dessus, franchement impressionnant. L'alignement ? C'est est-ce que le responsable produit, l'architecte, le développeur et la personne qui va s'asseoir devant cette affaire-là chaque jour à Montréal ou à Québec ont tous la même image dans la tête. Personne a encore construit d'outil pour cette partie-là. Personne.
La gueule de bois Copilot est l'accélération sans alignement. Construire la mauvaise chose, juste plus vite que jamais.
Trois clients. L'an dernier, on a vu ça se produire chez trois clients différents avec exactement le même scénario. Un responsable produit écrit un requis. Le dev le lit et imagine quelque chose de différent. L'intervenant qui avait demandé la fonctionnalité, lui, avait une troisième signification en tête. Personne attrape le décalage avant que le code soit écrit, déployé, et qu'il échoue à livrer de la valeur. Corriger l'erreur de requis ? Ça coûte 29 fois plus cher que si on l'avait attrapée à la planification (et ça surprend encore du monde). Le sondage Stack Overflow 2024 a confirmé quelque chose qu'on sentait dans nos tripes depuis des années : les devs passent plus de temps à comprendre les requis et à déboguer du code mal aligné qu'à écrire de nouvelles fonctionnalités. Et pourtant ? Les outils IA restent concentrés presque exclusivement sur la génération de code. Frustrant.
80 %. Rarement ou jamais utilisées. C'est pas un risque marginal, ça, c'est le poids accumulé de chaque sprint qui a déraillé parce que les hypothèses étaient pas validées, de chaque fonctionnalité livrée qui a pas résolu le vrai problème, de chaque projet où l'équipe a livré la spec parfaitement sauf que la spec elle-même était mauvaise. Le problème invisible, qui se cache au grand jour dans toute l'industrie depuis des décennies.
Quelle est la différence entre l'IA brouillon d'abord et l'IA décision d'abord ?
Ça m'a pris du temps. La plupart des outils IA aujourd'hui (Copilot, ChatGPT, toute la gang) fonctionnent en mode brouillon d'abord : on leur donne un prompt, ils nous retournent un document poli, complet, avec un ton professionnel et des assertions confiantes. C'est exactement ça le problème.
Mars dernier. On était dans une réunion de planification où le responsable produit avait demandé à ChatGPT d'écrire les requis pour un nouveau module de rapports. Le document était magnifique : des headings, des critères d'acceptation, des edge cases, la totale. Tout le monde hochait la tête. Personne a challengé. Pourquoi ils l'auraient fait ? L'IA avait déjà pré-répondu à chaque question, et les réponses avaient l'air correctes. Trois sprints plus tard ? On a découvert que le module assumait un accès en temps réel à un système qui synchronise juste la nuit. Un détail. Un seul. Et il serait sorti dans les cinq premières minutes d'une vraie conversation avec l'équipe des opérations.
C'est ça que les outils brouillon d'abord font : ils règlent le problème de la confiance tout en ignorant complètement le problème de l'alignement. Six mois. Ça m'a pris peut-être six mois à trouver le bon nom pour l'alternative : la pensée « décision d'abord ». L'idée est simple comme bonjour. Au lieu de générer un document, on liste les décisions qui doivent être prises et on force chaque personne dans la salle à les prendre pour vrai. Qui sont les utilisateurs réels ? Quelles contraintes existent ? Qu'est-ce qu'on sacrifie, et qui est confortable avec ce compromis-là ? Tant que ces décisions survivent pas à une vraie conversation (pas une session de hochement de tête avec une spec générée par IA), le code devrait même pas entrer dans le portrait.
Fondamental. Brouillon d'abord donne de la vitesse déguisée en complétude. Décision d'abord donne de la clarté. Et c'est la clarté, pas la vélocité, qui détermine si un projet réussit ou s'il finit dans la colonne « leçons apprises » du post-mortem que personne va lire.
Qu'est-ce que la gouvernance pré-code et pourquoi est-elle importante ?
Il manque quelque chose. Entre « on a une idée » et « on est prêts à coder », il y a un trou que personne comble. Pas de la bureaucratie, attention. De la gouvernance au sens pratique : est-ce qu'on a posé les bonnes questions ? Est-ce que nos réponses sont alignées ? Est-ce qu'on suit les compromis qu'on fait et qui les a approuvés ?
La gouvernance pré-code. C'est comme ça que j'appelle ça. Et elle est pratiquement absente du développement logiciel moderne. Les équipes passent d'une idée vague à du code détaillé en quelques heures. Résultat ? Du code rapide. Et mauvais.
Contre-intuitif, mais vrai : la gouvernance pré-code ne ralentit pas la livraison. Elle l'accélère. Quand on a la clarté sur ce qu'on construit et pourquoi, on arrête de construire les mauvaises choses, on élimine 40 à 50 pour cent du retravail qui se serait produit en aval, et on livre des fonctionnalités qui se déploient pour vrai parce qu'elles résolvent le bon problème. Comme on l'a exploré dans comprimer six semaines de requis en une journée, le temps épargné en aval dépasse largement le temps investi en amont.
Concrètement, une session de gouvernance pré-code prend une journée de travail. Quatre questions critiques, avant qu'une seule ligne de code soit écrite :
Qui sont les utilisateurs, et dans quel workflow on s'insère ? Pas un document de persona. Une description concrète : qui va utiliser cette fonctionnalité, ce qu'elle fait avant et après, le résultat qu'elle attend.
Quelles contraintes techniques sont 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 avoir commencé à coder, c'est comme ça que les équipes finissent par tout reconstruire de zéro.
Qu'est-ce qu'on ne construit PAS dans cette version ? Le périmètre se définit autant par ce qu'on exclut que par ce qu'on inclut. Rendre ces exclusions explicites prévient la dérive et les ajouts de type « tant qu'on y est » qui font dérailler les échéanciers.
Quels compromis fait-on, et qui les a approuvés ? Rapidité, qualité, coût, périmètre : chaque projet implique des compromis. Quand ils sont implicites, ils deviennent des surprises. Quand ils sont explicites et signés, ils deviennent des décisions. Le Standish Group CHAOS Report le confirme : les projets avec des requis clairs et l'implication des parties prenantes ont trois fois le taux de réussite de ceux qui s'en passent.
Octobre 2015, j'arrive chez Technology Evaluation Centers pour piloter une transformation numérique qui touche 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 bâtir tous leurs workflows eux-mêmes. Leur ambition : tout automatiser, lier les appels de vente à l'inventaire, les approbations juridiques, toute la chaîne. Ce qu'ils avaient réellement construit ? Un bazooka pour tuer un moustique. Une bête surcompliquée que personne ne comprenait et qui marchait à moitié.
Mon architecte Alexei Goldman et moi, on s'est assis avec chaque intervenant. Notre phrase d'ouverture : « Ne commençons pas par comment vous voulez que ce soit fait. Commençons par ce qui vous dérange. » On les a fait reculer du langage technique pour qu'ils nous parlent de leurs irritants, de leurs résultats idéaux, et des compromis qu'ils étaient prêts à accepter.
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 de calendriers et les allers-retours). Mais on a fini avec un système réellement maintenable, compréhensible pour tout le monde. La leçon : avant de plonger dans la construction, assurez-vous que tout le monde parle le même langage. L'alignement, c'est tout.
Comment adapter votre stratégie de codage IA avant qu'il ne soit trop tard ?
Un choix. Si vous utilisez Copilot (et 90 % des Fortune 100 le font), un choix s'impose maintenant. Option A : continuer comme la majorité des équipes avec un moteur de génération de code qui permet de coder plus vite sans confirmer qu'on code la bonne chose. Option B : intégrer Copilot dans une approche où le travail d'alignement se fait avant le code, pas après, pas en parallèle, avant.
Quatre étapes concrètes pour s'en sortir :
1. Clarifier les requis avant d'ouvrir l'IDE. Pas des semaines de réunions. Une session. Une seule session structurée où l'équipe s'aligne sur les besoins des utilisateurs, les contraintes techniques, les requis de sécurité et les compromis qu'on est prêts à faire. Décisions explicites, documentées, approuvées par les bonnes personnes.
2. Traiter les décisions comme un artéfact de première classe. Pas des documents. Des décisions. Pour qui on construit ? Quoi exactement ? Qu'est-ce qu'on exclut, et pourquoi ? Quels compromis on a faits et qui les a signés ? On les écrit, on les référence en revue de code, on les utilise pour détecter la dérive avant qu'elle devienne un problème à 500 000 $.
3. Impliquer les gens qui utilisent le logiciel. Pas à la démo, quand c'est trop tard. À la phase des requis. On s'intègre dans leur workflow quotidien comme je l'ai fait chez Technology Evaluation Centers à Montréal, et on comprend ce dont ils ont réellement besoin, pas ce qu'ils pensent pouvoir demander.
4. Traiter la vélocité du code comme un indicateur retardé. Utile. Mais pas une mesure du progrès. Mesurez l'alignement à la place : est-ce que les parties prenantes disent « oui, exactement » lors de la conception plutôt que « c'est pas ce que je voulais dire » lors du QA ?
La véritable opportunité Copilot
Depuis deux ans, on utilise l'IA pour accélérer l'exécution de la livraison logicielle. La vraie percée viendra quand on pointera cette même capacité vers la phase de réflexion : rendre plus facile de poser les bonnes questions avant le code, plutôt que moins cher de corriger les réponses après.
Les équipes qui saisissent ça en premier auront un avantage structurel qui se compose à chaque projet. Elles livreront 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
