Il y a huit mois, chez ExpertItLab, on a annoncé en interne qu'on avait divisé par deux le temps de dev sur un backoffice grâce à Copilot. On n'avait aucune donnée pour le prouver. On le sentait, c'est tout. Les suggestions tombaient vite, le code compilait, les tickets Jira se fermaient plus vite qu'avant. Toute l'équipe en était convaincue.
Trois mois plus tard, on a eu un bug en prod sur un module de paiement Mobile Money chez un client. Rien de dramatique, un arrondi mal géré sur une conversion de devise. Mais en creusant, on a réalisé que personne dans l'équipe 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à qu'on est tombés 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 nous a fait un choc, parce que c'est exactement ce qu'on vivait depuis huit mois. On se sentait plus rapides. On ne l'était peut-être pas.
La question qui nous 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 qu'on mesure le mauvais truc ? Et si on se sent plus productifs alors qu'on ne l'est pas, qu'est-ce qu'on est en train de perdre sans s'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 qu'on a utilisés nous-mêmes pour justifier l'abonnement Copilot à 19 dollars par dev par mois — une ligne de budget qui pèse quand on la convertit en francs CFA sur toute une équipe.
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, on ne mesurait pas ce deuxième temps. On comptait 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 une équipe ou un client : "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.
On ne dit pas que l'IA génère du mauvais code. On dit 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 — pour nous comme pour n'importe quelle équipe qui livre à des clients.
## Les juniors qu'on ne forme plus vraiment
C'est le point qui nous dérange le plus, et celui dont on ne parle jamais 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 chez ExpertItLab. 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 — on voit 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 pour nous : 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, on pense, 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 devant un client ou un board. 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 nos é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 qu'on n'a 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 à donner. 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 pour nous. 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.
On a changé d'avis sur un point précis. On ne demande plus à un dev "combien de temps t'a fait gagner l'IA sur ce ticket". On 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, probablement chez un client.
On n'a pas arrêté d'utiliser Copilot chez ExpertItLab. Ce serait malhonnête de prétendre le contraire, et un peu absurde vu où en est l'outil aujourd'hui. Mais on a arrêté de le compter comme un gain acquis. Sur du répétitif, oui, clairement, sans hésiter. Sur tout le reste, on vérifie notre propre sentiment de vitesse avant d'y croire, parce que l'étude METR nous a appris qu'on peut être convaincu d'avoir été rapide en ayant été lent.
Ce que ça pose comme question, on ne l'a 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 ? On n'a pas de réponse toute faite, et on se 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 ?
