Tous les articles

Journal

Humain + LLM > humain seul > LLM seul : pourquoi la maîtrise du logiciel reste la meilleure garantie

Les études convergent. Un développeur assisté par un LLM produit plus qu'un développeur seul, qui produit mieux qu'un LLM seul. Mais l'ordre ne tient qu'à une condition, celle qui compte vraiment pour un client.

Date
Lecture
11 min de lecture
Sujets
iallmingénieriequalitésécurité

Il y a deux discours faciles sur les modèles de langage appliqués au logiciel. Le premier dit que le développeur est en sursis : le modèle écrit le code, l'humain regarde. Le second dit que tout cela est un gadget qui produit du code fragile et qu'un vrai ingénieur s'en passe.

Les données disponibles en 2026 ne soutiennent ni l'un ni l'autre. Elles dessinent un ordre assez net :

humain + LLM > humain seul > LLM seul

… avec une clause que les deux discours oublient : cet ordre ne tient que si l'humain maîtrise le logiciel qu'il produit. Sans cette maîtrise, la combinaison passe sous l'humain seul. C'est la condition décisive, car c'est précisément ce qu'un client achète quand il confie un système à un prestataire.

LLM seul : rapide, plausible, et sans personne pour répondre

Commençons par le bas du classement. « LLM seul » n'existe pas vraiment en production : il y a toujours quelqu'un qui appuie sur merge. Mais le vibe coding, où l'on accepte la sortie du modèle sans la lire, en est une approximation honnête. Que sait-on de ce code-là ?

  • Le rapport GenAI Code Security 2025 de Veracode a testé plus de 100 modèles sur 80 tâches en Java, JavaScript, Python et C#. 45 % des échantillons introduisaient une vulnérabilité du Top 10 OWASP. En Java, 72 %. Et le point le plus dérangeant : les modèles plus récents et plus gros ne faisaient pas mieux que les petits ; la sécurité n'est pas un problème qui se règle en attendant la prochaine version.
  • L'étude de Stanford Do Users Write More Insecure Code with AI Assistants? (Perry et al., CCS 2023) a observé que les participants équipés d'un assistant écrivaient du code moins sûr sur quatre tâches sur cinq… et qu'ils étaient plus convaincus d'avoir écrit du code sûr que le groupe témoin. Le défaut et la confiance dans le défaut arrivent ensemble.
  • Côté maintenabilité, l'analyse GitClear 2025, sur 211 millions de lignes modifiées entre 2020 et 2024, mesure une multiplication par huit des blocs dupliqués et une chute du code déplacé ou refactoré, passé d'environ 25 % des lignes modifiées à moins de 10 %. 2024 est la première année du jeu de données où le copier-coller dépasse le refactoring.

Aucun de ces chiffres ne dit que le modèle est inutile. Ils disent qu'un code produit sans relecture compétente est un code dont personne ne peut garantir la sécurité ni l'évolution, et qu'en cas d'incident, il n'y a personne qui comprenne suffisamment le système pour le réparer. Le jugement s'exerce à deux endroits : en revue, sur le diff, et plus tard, sur ce qu'on arrive encore à comprendre cinq ans après.

Humain + LLM > humain seul : le gain est réel

Le haut du classement est mieux documenté qu'on ne le croit, et par des essais contrôlés, pas des sondages.

  • Le RCT GitHub Copilot (Peng et al., 2023) : 95 développeurs, un serveur HTTP en JavaScript à implémenter. Le groupe assisté termine 55,8 % plus vite.
  • Le RCT interne de Google (Paradis et al., 2024) : 96 ingénieurs, une tâche C++ réaliste avec complétion, smart paste et chat. Gain de temps estimé à environ 21 %, plus marqué chez ceux qui passent le plus d'heures à coder.
  • L'expérience BCG / Harvard Navigating the Jagged Technological Frontier (Dell'Acqua et al.) : 758 consultants. Sur les tâches à la portée du modèle, les consultants assistés accomplissent 12 % de tâches en plus, 25 % plus vite, avec une qualité supérieure de plus de 30 %. Le document de travail de 2023 avançait 40 % ; la version publiée dans Organization Science en 2026 l'a ramené à plus de 30 %, et c'est cette dernière que nous citons.
  • La méta-analyse de Vaccaro, Almaatouq et Malone dans Nature Human Behaviour (2024), sur 106 expériences et 370 tailles d'effet : comparé à l'humain seul, le tandem humain-IA l'emporte avec un effet moyen à large (g de Hedges = 0,64).

Sur ce point, le débat est clos : un développeur outillé produit plus qu'un développeur qui ne l'est pas.

… à condition que l'humain soit meilleur que la machine sur la tâche

C'est là que la même méta-analyse devient intéressante, et inconfortable. Vaccaro et ses coauteurs ne comparent pas seulement le tandem à l'humain seul ; ils le comparent au meilleur des deux pris isolément. Et là, en moyenne, le tandem perd (g = −0,23). Le détail vaut la lecture :

  • quand l'humain seul est meilleur que l'IA seule sur la tâche, la combinaison gagne (g = 0,46) ;
  • quand l'IA seule est meilleure que l'humain seul, la combinaison perd (g = −0,54).

Autrement dit, la valeur ajoutée du binôme vient de l'humain qui sait quand ne pas suivre la machine. Un humain qui ne peut pas juger la sortie n'ajoute rien : il retire.

L'étude BCG raconte la même chose sous un autre angle. Sur une tâche choisie hors de la portée du modèle, les consultants assistés avaient 19 points de moins de chances de produire une réponse correcte que ceux qui travaillaient seuls. Le modèle rend plus rapide et plus faux, en même temps, dès qu'on sort de sa frontière, et la frontière est irrégulière, on ne la voit pas depuis l'intérieur.

Deux autres résultats méritent d'être posés côte à côte :

  • L'essai contrôlé de METR (juillet 2025) : 16 mainteneurs open source expérimentés, 246 tâches sur leurs propres dépôts, cinq ans d'ancienneté en moyenne. Avec les outils de début 2025, ils étaient 19 % plus lents, tout en estimant avoir été 20 % plus rapides. En février 2026, METR a annoncé changer de protocole : la seconde vague, dix développeurs de la première plus quarante-sept nouveaux, estime un gain de 18 % pour les premiers et de 4 % pour les seconds, avec des intervalles de confiance qui contiennent zéro. METR considère ces chiffres comme un plancher, parce que les développeurs les plus convaincus refusent désormais de participer à une étude où il faut travailler sans IA. L'essai de 2025 reste la dernière mesure randomisée propre dont on dispose, et son remplaçant n'existe pas encore.
  • L'enquête de Microsoft Research The Impact of Generative AI on Critical Thinking (Lee et al., CHI 2025), auprès de 319 travailleurs du savoir : plus la confiance dans l'outil est élevée, moins la personne exerce d'esprit critique ; plus la confiance en soi est élevée, plus elle en exerce.

La conclusion tient en une phrase : le tandem vaut ce que vaut le jugement de l'humain. Pas son enthousiasme, pas son ancienneté, son jugement sur ce code précis.

Le piège : la maîtrise s'érode quand on ne l'exerce plus

Si la garantie repose sur le jugement humain, la question devient : que fait l'usage intensif du modèle à ce jugement ?

Anthropic (qui n'a aucun intérêt à noircir le tableau) a publié en février 2026 un essai contrôlé sur la formation des compétences : 52 développeurs apprennent une bibliothèque Python qu'ils ne connaissent pas, moitié avec assistant, moitié avec documentation et recherche seulement. Sur un quiz portant sur les concepts qu'ils venaient d'utiliser, le groupe assisté obtient 17 % de moins. Mais tous les usages ne se valent pas : ceux qui ont utilisé l'assistant pour comprendre (demander pourquoi ce motif, ce que fait cette ligne) ont retenu autant que le groupe témoin. Ceux qui ont délégué l'ont oublié.

Rien de neuf sous le soleil. Lisanne Bainbridge décrivait déjà en 1983, dans Ironies of Automation, le paradoxe des salles de contrôle : plus on automatise, plus l'opérateur se contente de surveiller, plus ses compétences manuelles se dégradent, et c'est exactement ces compétences qu'on lui demande le jour où l'automate échoue. Un opérateur expérimenté qui ne pratique plus devient un opérateur inexpérimenté.

Les développeurs le ressentent. Dans l'enquête Stack Overflow 2025, 84 % utilisent ou prévoient d'utiliser des outils IA, mais 46 % se méfient de leur exactitude (contre 31 % un an plus tôt), et la première frustration, citée par 66 %, est la réponse « presque juste, mais pas tout à fait ». 45 % disent que déboguer du code généré prend plus de temps que de l'écrire soi-même. « Presque juste » est le pire des cas : ça passe les tests évidents, et ça casse là où personne ne regarde.

Kasparov l'avait déjà formulé

Garry Kasparov raconte, dans The Chess Master and the Computer (2010), un tournoi freestyle de 2005 où humains et machines pouvaient s'allier librement. Des équipes de grands maîtres épaulés par plusieurs moteurs ont dominé les moteurs seuls. Mais le tournoi a été remporté par deux amateurs américains et trois ordinateurs, dont la force était de savoir comment faire travailler leurs machines. Sa formule :

« Un humain faible + une machine + un meilleur processus l'emportait sur un ordinateur puissant seul et, plus remarquable encore, sur un humain fort + une machine + un processus inférieur. »

Traduit en ingénierie logicielle : ce qui fait la valeur du binôme, ce n'est ni le modèle, ni le CV, c'est le processus, et un processus, c'est ce qui rend un résultat reproductible et vérifiable par quelqu'un d'autre.

À l'échelle d'une organisation, l'effet se voit dans les métriques de livraison

Les études individuelles racontent une chose ; les organisations en racontent une autre, qui va dans le même sens.

Le rapport DORA 2024 de Google mesurait qu'une hausse de 25 % de l'adoption de l'IA était associée à une baisse de 1,5 % du débit de livraison et de 7,2 % de la stabilité, alors même que la satisfaction et la productivité perçue des développeurs augmentaient. L'hypothèse des auteurs : produire du code plus vite gonfle la taille des lots, et les gros lots cassent plus.

Le rapport DORA 2025 résume la suite d'un mot : l'IA est un amplificateur. Les équipes qui ont déjà des fondations solides (petits lots, tests, revue, plateforme interne) accélèrent. Les équipes qui ont de la dette et des processus flous voient leurs problèmes grossir : plus d'échecs de changement, plus de reprises. Le temps gagné à écrire est redéployé à vérifier, et si personne n'est capable de vérifier, il est perdu.

Ce que cela veut dire quand vous confiez un système à quelqu'un

Ramenons tout cela au client. Quand vous achetez du logiciel, vous n'achetez pas des lignes ; vous achetez la capacité de quelqu'un à répondre de ces lignes dans deux ans, à trois heures du matin, quand la faille sera publique ou la dépendance abandonnée. Les études ci-dessus disent où se trouve cette capacité :

  1. Chez l'humain qui comprend le système. C'est la condition de la méta-analyse Vaccaro : le tandem gagne quand l'humain est meilleur que la machine sur la tâche. Un prestataire qui ne peut pas expliquer chaque décision d'architecture de son code ne peut pas non plus la garantir.
  2. Dans un processus qui vérifie, pas qui fait confiance. Revue humaine systématique, tests écrits avant ou avec le code, petits lots, environnements reproductibles. C'est la leçon de Kasparov et celle de DORA : le processus l'emporte sur la force brute.
  3. Dans une pratique qui entretient la compétence. L'étude d'Anthropic montre que l'usage qui fait comprendre préserve la maîtrise, et l'usage qui délègue l'érode. Bainbridge le disait il y a quarante ans. Une équipe qui n'écrit plus jamais de code à la main perd, silencieusement, la capacité de juger celui qu'on lui propose.

Chez adnap, nous utilisons ces outils tous les jours : ce serait absurde de se priver de l'accélération que nous constatons sur les tâches où elle est réelle, et nous ne la chiffrons pas ici parce qu'aucune des études ci-dessus ne mesure ce périmètre. Mais nous ne livrons rien que nous ne puissions relire, expliquer et corriger sans le modèle. Le LLM accélère l'écriture ; il ne porte pas la responsabilité. Cette responsabilité, c'est la maîtrise humaine du logiciel, et c'est la seule garantie que nous sachions donner honnêtement.

Sources

Prêt à reprendre la main sur votre technologie ?

Dites-nous où vous bloquez. Une vraie personne lit chaque message et répond sous 48 h ouvrées, avec une première piste concrète.

Nous contacter