Il y a huit mois, j'ai dit à mon associé qu'on avait divisé par deux le temps de dev sur notre backoffice grâce à Copilot. Je n'avais aucune donnée pour le prouver. Je le sentais, c'est tout. Les suggestions tombaient vite, le code compilait, les tickets Jira se fermaient plus vite qu'avant. J'étais convaincu.
Trois mois plus tard, on a eu un bug en prod sur le module de paiement Mobile Money. Rien de dramatique, un arrondi mal géré sur une conversion de devise. Mais en creusant, j'ai réalisé que personne dans l'équipe — moi y compris — ne pouvait expliquer ligne par ligne pourquoi ce bout de code faisait ce qu'il faisait. On l'avait accepté parce qu'il "avait l'air correct" et que les tests passaient.
C'est là que je suis tombé sur une étude de METR, un labo qui a mesuré, pas demandé, mesuré, le temps que mettent des développeurs expérimentés à résoudre de vrais tickets open source avec et sans IA. Résultat : ils mettent 19% de temps EN PLUS avec l'IA. Et après coup, ils continuent de croire qu'ils sont allés plus vite.
Ça m'a fait un choc, parce que c'est exactement ce que je vis depuis huit mois. Je me sens plus rapide. Je ne le suis peut-être pas.
La question qui me travaille depuis n'est pas "faut-il utiliser l'IA pour coder". Tout le monde l'utilise déjà, ici à Cotonou comme à San Francisco. La vraie question, c'est : est-ce que je suis en train de mesurer le mauvais truc ? Et si je me sens plus productif alors que je ne le suis pas, qu'est-ce que je suis en train de perdre sans m'en rendre compte ?
## Le paradoxe qu'on ne veut pas regarder en face
Sur le papier, les chiffres qui circulent sont impressionnants. Une étude menée avec Microsoft et Accenture sur près de 4 900 développeurs montre +26% de tâches complétées avec un assistant IA. GitHub, de son côté, a mesuré une tâche type terminée en 1h11 au lieu de 2h41 avec Copilot, soit 55% plus vite. Ce sont ces chiffres-là que les VP Engineering ramènent en board meeting. Ce sont ceux que j'ai utilisés moi-même pour justifier l'abonnement Copilot à 19 dollars par dev par mois — une ligne de budget qui pèse quand on convertit en francs CFA sur une équipe de six personnes.
Sauf que ces études mesurent des tâches courtes, isolées, souvent standard. L'étude METR, elle, a suivi des développeurs seniors sur des tickets réels, complexes, dans des bases de code qu'ils connaissaient déjà bien. Résultat inverse : 19% plus lents. Et une méta-analyse récente basée sur le modèle SPACE (celui que Google et Microsoft utilisent pour mesurer la performance des équipes dev) confirme : les devs se sentent plus efficaces, plus dans le flow, moins fatigués. Mais sur les dimensions objectives — performance réelle, activité, collaboration — rien ne bouge.
Autrement dit : deux études sérieuses, deux résultats opposés, et la différence tient à une seule variable — la complexité de la tâche. Sur du répétitif, l'IA est redoutable. Sur de l'architecture, de l'intégration, du debugging profond, elle coûte du temps qu'on ne compte pas, parce qu'on ne mesure jamais le temps passé à vérifier, corriger, comprendre ce que l'IA a produit.
Chez nous, personne ne mesure ce deuxième temps. On compte les tickets fermés, pas les heures de relecture.
## "Ça n'a pas dégradé la qualité" — vrai en moyenne, faux dans les cas qui comptent
Une étude sur l'adoption de Copilot dans des projets réels a comparé les métriques structurelles du code — complexité des fonctions, taille des modules — avant et après l'arrivée de l'IA. Verdict : aucune dégradation mesurable. C'est l'argument qu'on ressort le plus souvent pour rassurer : "regarde, les chiffres ne bougent pas, donc c'est sans risque".
Mais la même recherche note que Copilot échoue nettement dès qu'il s'agit de fonctions longues, de contextes multi-fichiers, ou de code métier spécifique — exactement le genre de code qu'on écrit sur un système de paiement local, avec ses règles de conversion, ses contraintes réglementaires BCEAO, ses cas limites qu'aucun modèle entraîné majoritairement sur du code américain ou européen n'a jamais vus.
Le bug qu'on a eu n'apparaît dans aucune métrique de complexité. Il était syntaxiquement propre. Il passait les tests qu'on avait écrits — avec l'IA, en partie. C'est ça le piège : une fausse sécurité qui a la forme du bon code sans en avoir la logique.
Je ne dis pas que l'IA génère du mauvais code. Je dis qu'elle génère du code qui a l'air bon, ce qui est un problème différent et plus difficile à détecter.
## Les juniors qu'on ne forme plus vraiment
C'est le point qui me dérange le plus, et celui dont personne ne parle en réunion budget. Anthropic a fait tester à des développeurs l'apprentissage d'une nouvelle librairie Python, une moitié avec IA, une moitié sans. Sur la vitesse d'exécution de la tâche : pas de différence significative. Sur un quiz de compréhension juste après : le groupe avec IA obtient 50%, le groupe sans IA 67%. Dix-sept points d'écart, l'équivalent de presque deux notes.
On a deux stagiaires cette année. Ils livrent vite. Ils utilisent Copilot ou ChatGPT pour à peu près tout, ce qui est normal, c'est l'outil disponible. Mais quand un bug sort en prod et qu'il faut comprendre pourquoi une fonction se comporte mal sans l'aide de l'IA — parce que parfois le contexte est trop spécifique pour qu'elle aide — je vois qu'ils sont perdus. Pas parce qu'ils sont mauvais. Parce qu'ils n'ont jamais eu à construire l'intuition que ça prend, normalement, deux ou trois ans à développer.
Aux États-Unis, plusieurs DRH et VP Eng interrogés par CIO.com le disent sans détour : ils embauchent moins de juniors, parce que l'IA fait une partie de ce travail-là. Ici, où le marché de l'emploi tech est déjà tendu et où beaucoup de jeunes diplômés se forment sur le tas, ça pose une question différente : dans cinq ans, qui seront nos seniors si personne n'a eu à galérer sans filet ?
## Ce qu'on choisit de mesurer, et ce qu'on choisit d'ignorer
Le vrai nœud, je crois, n'est pas technique. Il est dans les indicateurs qu'on affiche et ceux qu'on planque. Vélocité, tickets fermés, couverture de tests générés automatiquement — ça monte, ça se montre facilement, ça justifie le budget IA. La compréhension réelle du code par l'équipe, la capacité à diagnostiquer un incident sans assistant, la dette cognitive qui s'accumule — ça ne rentre dans aucun dashboard, donc ça n'existe pas pour la direction.
Et il y a une fracture silencieuse dans les équipes : les devs juniors et intermédiaires adoptent l'IA à fond et en tirent les gains les plus visibles à court terme. Les seniors, ceux qui ont vu l'IA se planter sur des cas tordus, restent plus prudents — et paraissent, sur le papier, "moins productifs". C'est une inversion étrange : la prudence devient un défaut de performance.
La question qu'on évite en réunion compliance
Il y a un dernier point que je n'ai vu traité nulle part publiquement, seulement chuchoté en interne. Dans les secteurs régulés — banque, assurance, fintech, tout ce qui touche à la BCEAO ou à la conformité UEMOA — on utilise déjà l'IA pour prototyper, parfois pour écrire directement des bouts de logique métier. Sans qu'on documente vraiment quelle part du code vient d'un humain et quelle part vient d'un modèle. Le jour où un régulateur ou un client demande "qui est responsable de ce bug, l'ingénieur ou l'outil qu'il a utilisé", on n'a pas de réponse propre. On a un historique Git qui mélange les deux, et une équipe qui, on l'a vu, ne comprend pas toujours en détail ce qu'elle a validé.
Ce n'est pas un problème théorique. C'est un problème qu'on repousse, comme on repousse la question de la formation des juniors, parce que les deux n'ont pas de ligne dans le tableau de bord trimestriel.
J'ai changé d'avis sur un point précis. Je ne demande plus à un dev "combien de temps t'a fait gagner l'IA sur ce ticket". Je demande "est-ce que tu pourrais réexpliquer ce code sans l'IA, à quelqu'un d'autre, dans six mois". Si la réponse est non, on n'a pas gagné du temps. On l'a emprunté, avec des intérêts qu'on paiera plus tard, probablement en prod, probablement au pire moment.
Je n'ai pas arrêté d'utiliser Copilot. Ce serait malhonnête de prétendre le contraire, et un peu absurde vu où en est l'outil aujourd'hui. Mais j'ai arrêté de le compter comme un gain acquis. Sur du répétitif, oui, clairement, sans hésiter. Sur tout le reste, je vérifie mon propre sentiment de vitesse avant d'y croire, parce que l'étude METR m'a appris qu'on peut être convaincu d'avoir été rapide en ayant été lent.
Ce que ça pose comme question, je ne l'ai pas résolue. Comment forme-t-on des juniors dans un métier où l'outil fait justement le travail qu'on utilisait pour apprendre ? Je n'ai pas de réponse toute faite, et je me méfie de quiconque en a une trop nette.
Si vous encadrez une équipe qui utilise l'IA au quotidien : est-ce que vous mesurez le temps gagné, ou seulement le temps qu'on croit avoir gagné ? Et vos juniors, dans deux ans, sauront-ils déboguer un système sans assistant — ou seulement le faire tourner ?
