Les erreurs commises par les équipes d'ingénieurs en 2026

Demande à n'importe quel responsable technique comment l'IA a changé son équipe, et tu auras une réponse optimiste. Demande-lui de le prouver avec des chiffres, et la plupart se taisent.

Cet écart, c’est l’histoire de 2026. Les ingénieurs, pris individuellement, sont plus rapides que jamais. Les équipes, dans bien des cas, ne le sont pas. On a discuté avec notre propre équipe d’ingénieurs, ceux qui ont passé l’année dernière à développer et à lancer Upsun Dispatch™ et qui ont vécu cette évolution de près, et la même tension est revenue sans cesse : ce qui rend une personne nettement plus productive peut rendre le groupe qui l’entoure plus lent, plus désorganisé et plus difficile à gérer.

Voici ce qu’ils nous ont dit.

Le coût devient un problème de fiabilité

Demande à une équipe d’ingénieurs qui développe des processus IA quelle a été leur plus grande surprise cette année, et beaucoup te répondront : la facture.

Patrick Dawkins, ingénieur logiciel principal, a expliqué qu’une même tâche de codage coûtait la plupart du temps un dollar et parfois dix dollars, sans qu’on puisse savoir à l’avance quel sera le montant avant la fin de la tâche. Guillaume Moigneu, directeur technique sur le terrain chez Upsun, a vu le coût de la révision d’une seule pull request varier entre cinq centimes et quarante dollars.

La solution, ce n’est pas de réduire les dépenses. C’est la visibilité : des coûts suivis en temps réel, par processus et par équipe, avec des budgets fixés avant la mauvaise surprise plutôt que justifiés après coup.

Personne n’a de référence pour comparer

La plupart des entreprises ne peuvent pas vraiment prouver les gains de productivité qu’elles pensent réaliser, car presque aucune d’entre elles n’a rien mesuré avant de se lancer.

Sans chiffre « avant », chaque affirmation sur la rapidité apportée par l’IA n’est qu’une supposition déguisée en indicateur. Les équipes qui ont investi tôt dans la mesure de référence sont celles qui peuvent aborder une discussion budgétaire avec un exemple concret. Tous les autres s’appuient sur des impressions.

Un seul ingénieur rapide peut ralentir toute une équipe

Guillaume Moigneu développe des logiciels depuis 28 ans. Il a observé ce qui se passe quand, dans une petite équipe, une personne adopte les agents plus vite que tout le monde.

« Si tu fais partie d’une équipe de trois ou quatre personnes, le fait d’avoir un ingénieur comme ça peut poser pas mal de problèmes aux autres », nous a-t-il expliqué. 

Une personne qui déploie 50 modifications assistées par l’IA en un week-end, ça ne ressemble pas à une victoire pour le reste de l’équipe le lundi matin. Ça ressemble plutôt à un retard accumulé. 

« Tu te réveilles et tu vois que Patrick a bossé tout le week-end, qu’il a fait genre 50 modifications différentes, et tu te dis : “Oh, je vais devoir tout refaire, je vais devoir m’assurer que tout fonctionne.” C’est le bazar. »

La vélocité individuelle et la vélocité d’équipe ne sont pas les mêmes indicateurs, et optimiser l’une peut discrètement nuire à l’autre.

L’attention humaine ne s’adapte pas de la même manière que les agents

Patrick Dawkins a développé un outil interne qui examine les demandes de fusion avant qu’un humain ne les voie. Il a aussi découvert les limites de la supervision de plusieurs agents à la fois.

Gérer un seul agent, c’est faisable. Mais dès qu’il peut tourner sans surveillance pendant un moment, l’ennui s’installe, et tu en lances un deuxième. Puis un troisième. « Tu te retrouves à penser à trois choses différentes en même temps », explique Dawkins. « Je ne pense pas que tu puisses vraiment tenir plus de quelques heures par jour avant de finir par t’épuiser. »

C’est une contrainte difficile à gérer, pas un problème de formation. Les équipes qui considèrent « lancer plus d’agents » comme un levier de productivité gratuit ont tendance à l’apprendre à leurs dépens.

Les agents locaux ont créé un angle mort dans la gouvernance

Pendant la majeure partie de la fin de l’année 2025, les ingénieurs ont fait tourner des agents sur leurs propres ordinateurs portables. Avec le recul, explique Dawkins, ça a créé un vrai risque.

« T’es le seul à voir ce que fait l’agent sur ton ordinateur portable. Ça n’est pas visible pour le reste de ton entreprise », a-t-il expliqué. « Si un ingénieur dépense des milliers de dollars dans son outil d’IA, tu ne vois pas les résultats, ou alors tu vois peut-être le résultat mais tu ne comprends pas pourquoi ça coûte si cher. Et tu ne vois pas si les données clients sont envoyées au mauvais endroit. »

Tu fermes l’ordinateur portable, et l’agent s’arrête. Et comme tout tournait en local, personne en dehors de la machine de cet ingénieur n’avait de visibilité sur les dépenses, les résultats ou ce qui sortait de l’entreprise.

La plupart des équipes sont plus en retard qu’elles ne le pensent

Un cadre interne qu’on a découvert décompose l’adoption de l’IA en plusieurs étapes, et c’est un bon moyen de vérifier où en est réellement ton équipe.

Ça commence par des individus qui adoptent l’IA de leur propre chef, sans direction, sans politique, chacun achetant ses propres abonnements. C’est normal, voire sain, comme point de départ. Le problème, c’est ce qui suit : certains ingénieurs prennent une longueur d’avance sur les autres, chacun développant des outils et des prompts privés qui ne sont jamais partagés. Puis, quelques équipes industrialisent leurs processus tandis que d’autres continuent de travailler comme si on était en 2024. L’écart entre les équipes les plus rapides et les plus lentes devient visible, et la direction est généralement incapable d’expliquer pourquoi.

C’est exactement là où se trouvent la plupart des organisations en ce moment, qu’elles veuillent l’admettre ou non.

La confiance, c’est un curseur, pas un interrupteur

Le modèle mental le plus clair qui est ressorti de nos discussions vient de Moigneu : traite un agent comme une nouvelle recrue.

« Au début, tu leur expliques en quoi consiste le travail, quelles sont les règles, puis pendant le premier ou les deux premiers mois, tu fais confiance mais tu vérifies », a-t-il déclaré. « Pour les agents, c’est la même chose. Au début, on met en place ce qu’on appelle des “contrôles humains” : après chaque tâche critique ou risquée, un humain doit vérifier ce que l’agent a fait et l’approuver, le rejeter ou en discuter. »

Le contrôle en soi n’est pas l’essentiel. C’est la boucle de rétroaction qui compte. À mesure que le processus fait ses preuves, les contrôles s’allègent. Si tu changes la couleur d’un bouton, tu n’as pas besoin de cinq validations. Mais si tu modifies la façon de déclarer ses impôts à l’administration, tu auras probablement besoin de plus d’une validation.

Le travail passe de l’écriture de code à son évaluation

Tous les ingénieurs à qui on a parlé ont décrit la même évolution : moins de temps passé à taper, plus de temps à relire, vérifier et décider si le travail généré par l’IA est bien correct.

Moigneu présente ça comme une évolution du métier de codeur vers celui d’architecte. « C’est toi qui es responsable de tout ce qu’écrit un LLM », comme l’a dit Patrick Dawkins. « Lire chaque ligne de code, comprendre ce qu’elle fait, c’est super important. »

Ce qui distingue les équipes qui réussissent

Si on fait abstraction des détails, une tendance se dégage de toutes les conversations. 

Les équipes qui peinent en 2026 optimisent pour l’ingénieur individuel, font tourner des agents sans aucune visibilité sur les coûts ou les résultats, et passent directement à l’automatisation totale sans véritable période de renforcement de la confiance. 

Les équipes qui s’en sortent mieux considèrent l’adoption de l’IA comme un problème de conception organisationnelle : des normes partagées plutôt que des configurations individuelles, un « indicateur de confiance » plutôt qu’une foi aveugle, une visibilité sur les coûts plutôt que des surprises en fin de mois.

Rien de tout ça n’a rien d’exotique. C’est la même discipline dont les équipes d’ingénieurs ont toujours eu besoin dès qu’elles dépassent une seule personne. L’IA a juste considérablement raccourci le délai pour l’apprendre.

C’est exactement le modèle sur lequel Upsun Dispatch™ a été conçu, parce qu’on l’a nous-mêmes mis en pratique en premier : des agents fonctionnant dans une couche partagée plutôt que sur des ordinateurs portables individuels, des contrôles humains qui s’assouplissent à mesure que la confiance s’installe plutôt que de rester en place indéfiniment, et des coûts suivis en temps réel plutôt que découverts à la fin du mois.

• Tu es nouveau ici ? Lis l’introduction à Upsun Dispatch
• Tu veux contribuer à son développement ? Postule pour rejoindre la promotion des partenaires fondateurs en conception