L'IA n'a pas remplacé vos développeurs. Elle a supprimé la revue.

Aug 20, 2026 min read
L'IA n'a pas remplacé vos développeurs. Elle a supprimé la revue.

Le débat sur l’IA et les développeurs est mal posé depuis le départ. On se demande si elle va les remplacer, alors que la vraie question est ailleurs, et qu’elle est déjà tranchée dans les chiffres.

Écrire du code n’a jamais été le goulot d’étranglement. Le goulot, c’était de le relire.

Et on vient de multiplier par dix le côté production sans toucher au côté relecture.

Ce que disent les chiffres

Le rapport DORA 2025 est le document le plus solide qu’on ait sur le sujet, parce qu’il mesure des équipes réelles plutôt que des impressions.

Deux constats, à mettre côte à côte.

Le premier : 90 % des professionnels de la tech utilisent désormais l’IA au travail, et plus de 80 % estiment qu’elle a augmenté leur productivité. Ce n’est plus une tendance, c’est l’état du secteur.

Le second est plus intéressant. En 2024, DORA constatait que l’adoption de l’IA était corrélée négativement au débit de livraison — autrement dit, ça ralentissait. En 2025, c’est inversé : la corrélation avec le débit est devenue positive. On livre bel et bien plus vite.

Mais la corrélation avec la stabilité de livraison reste négative. Elle l’était en 2024, elle l’est toujours.

Traduisez : on livre plus, et ça casse plus. Les auteurs résument ça en disant que l’IA est un amplificateur — elle grossit les forces de l’organisation comme ses faiblesses. Je trouve la formule juste, mais un peu douce. Ce que j’y lis, moi, c’est que la production a accéléré et que le contrôle est resté sur place.

Le goulot n’a pas disparu, il s’est déplacé

Prenez une équipe de six personnes. Avant, elle produisait mettons dix pull requests par semaine, et elle en relisait dix. L’équilibre était pénible mais il tenait.

Aujourd’hui, la même équipe en produit trente. Combien en relit-elle vraiment ?

Vous connaissez la réponse, parce que vous la voyez tous les jours, et parce que vous l’avez fait vous-même vendredi dernier. Elle en relit dix sérieusement, et elle en approuve vingt en diagonale.

Et c’est parfaitement rationnel de la part des relecteurs. Personne n’a le temps de lire attentivement trois fois plus de code sans que rien d’autre ne saute. Alors ce qui saute, c’est la profondeur de la lecture — silencieusement, sans qu’aucune décision ne soit prise, sans que personne ne l’annonce en réunion.

Il y a même un effet plus vicieux. Le code généré est plus agréable à lire que le code écrit à la main. Il est bien indenté, les noms sont cohérents, les commentaires sont présents. Il inspire confiance à la lecture rapide, et c’est précisément ce qui le rend dangereux : la relecture superficielle, qui attrapait des choses quand le code était moche, n’attrape plus rien.

Je le dis autrement, parce que c’est le cœur du sujet : on a rendu la production dix fois plus rapide et la relecture dix fois plus difficile à faire honnêtement.

« L’IA n’a qu’à relire »

C’est là qu’on me sort la solution évidente : mettre un modèle sur la relecture aussi.

Ça marche, en partie. Pour les fautes de frappe, les conventions, les vulnérabilités connues, les erreurs de type, un relecteur automatique est excellent, infatigable et pas cher. Utilisez-le, franchement.

Mais regardons ce que fait une revue de code quand elle est bien menée, parce qu’on l’oublie :

  • elle vérifie que le code fait ce que le ticket demandait, ce qui suppose de savoir ce que le métier voulait vraiment ;
  • elle repère qu’on réimplémente pour la troisième fois un truc qui existe déjà dans le dépôt d’à côté ;
  • elle dit « attends, on avait décidé le contraire il y a six mois, et voilà pourquoi » ;
  • elle transmet. C’est là que les jeunes apprennent le métier, et pas ailleurs ;
  • et elle engage quelqu’un. Une revue signée, c’est un humain qui met son nom en face d’un changement.

Sur combien de ces cinq points un modèle est-il capable de vous remplacer ? Aucun.

Il n’a pas le contexte de la décision d’il y a six mois, il ne transmet à personne, et surtout il n’engage rien du tout.

Sur ces cinq points, donc, un modèle est nul ou absent. Le dernier point est le plus important, et c’est celui dont on ne parle jamais. Une revue, ce n’est pas seulement un filtre technique. C’est un transfert de responsabilité. Quand plus personne ne relit vraiment, plus personne ne répond de rien, et vous vous en apercevez le jour de l’incident.

Ce que ça donne dans six mois

Je ne fais pas de prédiction hasardeuse, je décris ce que j’ai déjà vu s’installer.

Quand avez-vous relu pour la dernière fois un fichier que personne de votre équipe n’avait jamais ouvert ?

Un dépôt qui grossit plus vite que la compréhension qu’en a l’équipe. Des morceaux entiers que personne n’a jamais lus attentivement, y compris celui qui les a validés. Une incapacité croissante à répondre à la question la plus banale du métier : pourquoi c’est fait comme ça ?

Cette dernière question est le vrai marqueur. J’écrivais dans l’article sur la dette technique que la documentation ne survit pas et que le savoir finit dans quelques têtes. Là c’est pire : le savoir n’a jamais existé dans aucune tête. Le code a été produit par quelque chose qui n’a aucun souvenir de l’avoir écrit, validé par quelqu’un qui l’a survolé.

Et l’instabilité que mesure DORA n’est rien d’autre que ça, exprimé en incidents.

Alors on fait quoi

Une seule idée, mais elle a des conséquences partout : si la production accélère, le contrôle doit accélérer autant, sinon il faut ralentir la production. Il n’y a pas de troisième option, même si tout le monde essaie d’en trouver une.

Concrètement, quatre leviers, dans l’ordre où je les mettrais en place :

  • rendre le changement plus petit. Une revue sérieuse est possible sur cent lignes, impossible sur mille. Si l’IA vous fait produire davantage, découpez davantage. C’est la mesure la moins chère et la plus efficace ;
  • déplacer le contrôle vers l’automatique partout où c’est possible. Tests, analyse statique, politiques de sécurité, vérification des schémas. Tout ce qu’une machine peut refuser toute seule libère du temps humain pour ce que seule une machine ne peut pas juger ;
  • exiger que l’auteur ait lu. Pas « l’IA l’a écrit ». Vous soumettez, vous répondez de chaque ligne, y compris celles que vous n’avez pas tapées. C’est une règle culturelle, elle se pose en réunion et elle se tient ;
  • surveiller la stabilité, pas la vélocité. Taux d’échec des changements et délai de rétablissement. Si le débit monte et que ces deux-là se dégradent, vous savez exactement ce qui se passe, et vous avez le chiffre pour le dire à votre direction.

En conclusion

L’IA n’a pas remplacé les développeurs, et à mon avis elle ne les remplacera pas de sitôt. Ce qu’elle a fait est à la fois plus discret et plus embêtant : elle a rompu un équilibre entre production et contrôle qu’on avait mis vingt ans à trouver, et personne n’a rien décidé.

C’est exactement le motif que je décrivais à propos des équipes plateforme. Il n’y a pas de méchant, il n’y a pas de mauvaise décision. Il y a une pente, et tout le monde la descend en trouvant ça normal.

Le vrai travail des prochaines années, ce n’est pas d’écrire plus de code. C’est de retrouver un moyen de répondre de celui qu’on livre.

Un code que personne n'a lu n'a pas d'auteur. Il a juste un coupable, plus tard.

Sources

-|