- IA
- Développement
Deux ans d’IA en développement logiciel : ce qui a tenu, ce qui a changé
4 novembre — 2026
En novembre 2024, nous avons publié un texte qui annonçait une prise de position forte pour Mirego : l’adoption généralisée des outils de développement utilisant l’IA générative dans tous nos projets, pour tous nos clients. Un an plus tard, en octobre 2025, nous avons fait le point sur nos apprentissages, nos résultats et notre vision du futur.
Nous voici en novembre 2026, et beaucoup de choses ont encore changé. Au cours des deux dernières années, nous avons fait des affirmations publiques assez tranchées sur la façon dont nous voulions utiliser l’IA. Le moment est venu de les confronter à la réalité.
Disons-le d’emblée : nous n’avons pas toutes les réponses. Comme le reste de l’industrie, nous sommes toujours en train de comprendre à quoi ressemblera réellement le développement logiciel dans quelques années. Nous n’attendons pas que quelqu’un trouve les réponses pour nous : nous allons les chercher nous-mêmes.
Ce que nous avions affirmé
Trois affirmations de nos textes précédents méritent qu’on y revienne :
2024
« Ces outils ne remplacent pas des membres de l’équipe de développement, ils les amplifient. »
2024
« Chaque ligne de code d’un projet a été soumise par un·e développeur·euse, assisté·e par l’IA ou pas. »
2025
« Plutôt que d’envisager un futur où les développeur·euse·s agissent en “gestionnaires d’agents IA” qui coordonnent une multitude d’agents travaillant en parallèle […], notre vision s’apparente plus à celle des chirurgien·ne·s. »
La première affirmation tient toujours. La deuxième et la troisième, par contre, ont été mises à rude épreuve cette année. Nous y reviendrons.
Avant cela, parlons d’un sujet que nous avions presque complètement ignoré dans nos deux premiers textes.
Un nouvel enjeu : le coût réel
En 2024 et en 2025, nous avions identifié deux enjeux principaux : la confidentialité des données et du code source de nos clients, ainsi que le risque de diminuer la qualité de ce que nous livrons. Ces deux enjeux sont toujours présents. En 2026, un troisième s’est imposé : le coût réel de l’IA.
Pendant longtemps, la question du coût était facile à ignorer (certains l’ignorent même encore). Les abonnements étaient forfaitaires, souvent généreusement subventionnés par les fournisseurs, et la consommation de tokens restait marginale. Avec la généralisation des agents capables d’exécuter des tâches de A à Z (et de consommer des millions de tokens en le faisant), cette époque est révolue.
Nous avons appris une chose importante : le coût d’un token ne veut pas dire grand-chose. Ce qui compte, c’est le coût d’une tâche.
Un modèle deux fois moins cher qui a besoin de trois itérations, qui prend des décisions discutables et qui exige une heure de révision supplémentaire n’est pas deux fois moins cher. Il coûte beaucoup plus cher. L’inverse est aussi vrai : utiliser le modèle le plus puissant du marché pour renommer une variable ou générer un fichier de configuration est du gaspillage.
Le coût réel d’une tâche inclut donc :
les tokens consommés (incluant les itérations ratées);
le temps humain consacré à rédiger le plan de match technique;
le temps humain consacré à réviser, corriger et ajuster le résultat;
la dette de compréhension accumulée lorsque personne ne maîtrise réellement le code produit.
L’exemple que nous avions partagé en 2025 (six heures de rédaction de plan de match pour générer l’équivalent d’une quinzaine de jours de développement, suivies d’une dizaine de jours de corrections manuelles) illustre parfaitement ce phénomène : le coût en tokens était négligeable; le coût réel, lui, ne l’était pas.
Le bon modèle pour la bonne tâche
Notre texte de 2024 commençait par cette phrase : « Nous croyons que c’est avec les meilleurs outils que se bâtissent les meilleurs produits. » Nous croyons encore profondément en cet énoncé. En 2026, l’outil dont le choix a le plus d’impact n’est plus l’éditeur de code ni même l’agent. C’est le modèle choisi pour chaque tâche, en combinaison avec le harnais qui l’encadre.
C’est ce qu’on appelle le model routing. Plutôt que d’utiliser un seul modèle pour tout, nous dirigeons chaque tâche vers le modèle le mieux adapté selon sa complexité, sa criticité et ses contraintes :
Les modèles de pointe (frontier) pour la planification, l’architecture, l’analyse de code complexe et la rédaction de plans de match techniques, c’est-à-dire là où la qualité du raisonnement a un impact direct sur tout ce qui suit.
Les modèles plus rapides et moins coûteux pour l’exécution de tâches bien définies : implémentation d’un plan précis, génération de tests à partir d’exemples existants, migrations, refactors mécaniques.
Les modèles exécutés localement sur nos machines ou dans nos bureaux pour les clients qui ont des exigences spécifiques de souveraineté des données, comme nous le mentionnions déjà en 2024.
L'ascension en popularité, en performance et en cost-efficiency des modèles frontier à poids ouverts (open weight) comme GLM, DeekSeek, Qwen et Kimi a également contribué à élargir notre éventail de possibilités.
L’arrivée récente de modèles System One comme Jev, Clef ou Clairic nous a aussi ouvert à de nouvelles possibilités d’intégration d’IA à travers nos systèmes et processus, là où l’utilisation d’un LLM était auparavant trop lourd ou inefficace.
Moins d’humain dans la boucle, moins d’ownership?
C’est sur ce point que nos affirmations précédentes ont été le plus remises en question.
En 2026, le concept de software factory (des chaînes d’agents capables de passer d’une spécification à une pull request, voire jusqu’au déploiement, avec une intervention humaine minimale) est passé du statut de curiosité à celui de réalité. Nous avons commencé à le mettre en place dans nos projets. Malgré notre position de 2025 en faveur du modèle des chirurgien·ne·s, nous aurions manqué à notre devoir en ne l’explorant pas sérieusement.
Ce que nous avons constaté est nuancé. Pour certaines catégories de tâches (code standardisé, migrations répétitives, mises à jour de dépendances, couverture de tests), ces approches fonctionnent remarquablement bien. Pour d’autres, elles soulèvent des questions auxquelles nous n’avons pas encore de réponses définitives.
La dette de compréhension
En 2024, dans le cadre de la refonte de la plateforme de La Ruche, nous expliquions que l’IA nous avait aidés à « développer un ownership sur le code plus rapidement ».
Aujourd’hui, la question se pose à l’inverse : plus on confie des tâches complètes à des agents, plus on risque de produire du code qui fonctionne, qui passe tous les tests, mais que personne dans l’équipe ne comprend réellement. Au niveau micro (implémentation), c’est probablement négligeable mais au niveau macro (architecture), c’est potentiellement un problème à long terme, autant au niveau technique que fonctionnel.
La revue de code comme goulot d’étranglement
Lorsque la production de code n’est plus une contrainte, la capacité humaine à le valider le devient. Une revue de 2000 lignes générées en quelques minutes n’a pas la même valeur qu’une revue de 200 lignes écrites avec intention.
Nos processus SDLC qui s’appuient sur des outils déterministes (analyses statiques, balayages de vulnérabilités, tests automatisés) sont plus cruciaux que jamais, mais ils ne remplacent pas la compréhension.
Nous sommes en train de revoir nos principes de revue de code pour s’assurer que chaque effort investi (humain ou machine) est le bon et déterminer quels compromis nous pouvons faire pour augmenter notre vélocité sans compromettre la qualité de ce que nous produisons.
La relève
En 2025, nous affirmions que le jugement du·de la développeur·euse prend de plus en plus de valeur. Une question nous préoccupe : comment une personne en début de carrière développe-t-elle ce jugement si elle écrit et lit de moins en moins de code elle-même?
Nous n’avons pas encore de réponse satisfaisante, mais nous refusons de faire comme si la question n’existait pas.
Un engagement reformulé
Notre affirmation de 2024 (« chaque ligne de code a été soumise par un·e développeur·euse ») était juste à l’époque. Aujourd’hui, elle ne capture plus l’essentiel. Que le code ait été tapé par un humain ou généré par un agent importe moins que la question suivante : est-ce qu’un humain le comprend et en assume la responsabilité?
✦ La question n’est plus de savoir qui a écrit le code, mais qui en répond.
Notre engagement pour 2026 envers nos projets clients est donc le suivant : chaque changement livré dans un projet Mirego a un·e responsable humain·e qui en répond. Nous acceptons de retirer l’humain de certaines étapes d’exécution. Nous refusons de le retirer de l’architecture, de la sécurité et des décisions de produit.
Toujours en train d’apprendre
Si une chose se dégage de ces deux dernières années, c’est que personne (ni nous, ni nos pairs, ni les fournisseurs de modèles eux-mêmes) ne sait exactement où tout cela nous mène. Ceux qui prétendent le contraire vendent probablement quelque chose.
Ce que nous savons, par contre, c’est comment nous voulons avancer : en innovant à travers l’expérimentation. L’innovation a toujours été le moteur de Mirego, et elle doit le rester.
Cela veut dire tester de nouvelles approches, même lorsqu’elles contredisent nos positions précédentes. Cela veut dire les appliquer sur de vrais projets, prendre le temps de mesurer leurs impacts réels (autant les impacts positifs que les compromis à faire) et avoir l’humilité de se réajuster lorsque les résultats ne sont pas satisfaisants.
✦ Deux pas en avant, on évalue la situation, un pas en arrière. Et on recommence.
C’est exactement ce que nous avons fait cette année avec les software factories et les revues de code. C’est ce que nous continuerons à faire l’an prochain avec ce qui viendra ensuite.
Toujours vers le futur
Aujourd’hui, en novembre 2026, notre vision des chirurgien·ne·s tient toujours, mais elle a évolué. Un·e chirurgien·ne ne travaille jamais seul·e : une équipe l’entoure, prépare, assiste et prend en charge les étapes qui ne requièrent pas son expertise.
Les agents font maintenant partie de cette équipe. Le rôle du·de la développeur·euse n’est pas encore de les gérer comme une flotte, mais de rester aux commandes des décisions qui comptent.
À travers tous les changements de ces deux dernières années, un seul élément n’a pas bougé. Il s’agit de notre principe non négociable : nous bâtissons des produits de qualité (autant au niveau UI/UX pour nos produits qu’au niveau maintenabilité pour notre code) qui ont de l’impact.
Ni les outils, ni les modèles, ni les software factories ne doivent remettre ce principe en question.
Abonnez-vous à notre infolettre
Recevez des analyses sur les tendances technologiques, des perspectives sur l'IA et le développement, ainsi que notre veille mensuelle de l'actualité numérique.
