L’artisanat du numérique : un métier en mutation L’ingénieur informatique en 2026 : d’artisan numérique au manager d’agents IA

L’IA ne remplace pas les ingénieurs, elle transforme leur métier. Alors que les agents logiciels deviennent capables de produire des pans entiers d’applications, la valeur se déplace vers l’analyse, l’architecture, la spécification et le discernement. Après 18 ans d’artisanat numérique, nous partageons notre regard sur cette mutation qui redéfinit déjà le rôle des développeurs et des bureaux d’études logiciels.

L’artisanat du numérique : un métier en mutation
 
 Pendant longtemps, le métier d’ingénieur logiciel était un métier avec une grande part opérationnelle.

Concevoir une architecture, développer des fonctionnalités, corriger des bugs, optimiser des performances : l’essentiel de la valeur produite passait directement par la capacité à fabriquer du logiciel “à la main”.
 
 Au fil du temps (et bien avant l’arrivée de l’IA), les outils mis à disposition des développeurs ont grandement évolué, on est ainsi passé d’écrire du code avec un simple éditeur de texte « noir sur fond blanc » (ou l’inverse pour les puristes) à des « IDE » (environnement de développement intégré fournissant de multiples outils) puis à l’intégration de préprocesseurs de code de plus en plus performants et évolués bloquant littéralement la soumission de code si les règles ne sont pas respectées.
 
 Cette mutation a toujours visé les mêmes objectifs : accélérer l’écriture du code, augmenter sa qualité, uniformiser le code entre les développeurs et réduire le temps d’apprentissage.
 Chacune de ces innovations a entraîné des controverses et des craintes dans la communauté des développeurs, surtout pour nos aînés qui écrivaient chaque caractère en début de carrière et devaient maîtriser la syntaxe à la perfection.

Mais ces dernières années — et particulièrement ces six derniers mois — quelque chose a changé de nature.

L’arrivée massive des assistants IA dans les environnements de développement vise plus simplement un gain de productivité : elle vise à modifier profondément le rôle même de l’ingénieur informatique.

Chez Kapt, après 18 années à concevoir des plateformes métiers, simulateurs, outils SaaS et applications sur-mesure, nous observons une bascule très nette dans la communauté : l’ingénieur deviendrait progressivement moins un “artisan du code” qu’un chef d’orchestre d’agents logiciels spécialisés.
 
 En mai 2026, Arthur Mensch, cofondateur et CEO de Mistral AI, déclarait devant l'Assemblée nationale ce que beaucoup pressentaient sans encore l'assumer : "Aujourd'hui, les ingénieurs chez Mistral n'écrivent plus de lignes de code. Avant, c'était un artisanat. Aujourd'hui, vous n'êtes plus un artisan, vous êtes un manager."

Ces mots ne sont pas de la provocation. Ils décrivent ce que nous observons chez de nombreux confrères, avec une forte accélération depuis plus de six mois.

Nous sommes face à une mutation de la société toute entière, une mutation potentiellement irréversible face à laquelle il faut s’adapter.

2026, les 6 mois qui ont « tout » changé (ou marquer un cap)

Le développement logiciel est en pleine mutation, surtout ces 6 derniers mois.
 
 Nous nous sommes toujours considérés comme des artisans du numérique. Nous aimons cet artisanat, … et nos clients aussi.

Nous faisons facilement le parallèle entre notre métier et celui d’un électricien ou d’un ébéniste qui construit avec passion quelque chose de sur-mesure sans jamais renier sur la qualité.

Ça n’est pas ce que nous prônons chez Kapt, mais nous devons nous rendre à l’évidence : aujourd’hui de plus en plus d’ingénieurs logiciel avouent devenir des donneurs d’ordre, des gestionnaires d’agents qui co-écrivent du code à partir des spécifications elles mêmes « promptées » par les ingénieurs.
 
 La transformation des outils IA n'est pas linéaire. Pendant des années, les assistants de code aidaient à aller plus vite — un peu comme une autocomplétion évoluée. Mais depuis fin 2025, quelque chose a basculé. Les agents IA ne complètent plus le travail du développeur : ils sont capables d’exécuter des tâches entières sur instruction. Générer une API, structurer une base de données, re-factoriser un module, rédiger des tests — tout cela peut se déléguer désormais à des agents, en langage naturel.

Arthur Mensch évoque des gains de productivité d'un facteur 10 à 20 pour un ingénieur seul.
 Ce chiffre (plutôt exagéré de notre point de vue) est également avancé par les acteurs américains comme Anthropic et OpenAI .
 Il doit néanmoins être pris avec précaution car il y a de nombreuses tâches sur lesquelles nous n’observons pas en pratique ces gains de productivité, ni chez Kapt, ni chez nos confrères.
 On déchiffre bien dans ces chiffres la stratégie marketing de ces géants et dont l’objectif à court terme est d’avoir une adoption massive de leurs outils pour les rendre indispensables avant que la bulle de l’IA n’explose.
 Une fois ce constat (un peu rabat-joie je vous l’accorde) fait, nous devons bien reconnaître que sur beaucoup de tâches, l’IA a rebattu les cartes.
 
 Par exemple, sur des tâches de spécifications et de prototypage qui mobilisaient trois personnes, un ingénieur bien outillé suffit.
 L’IA est vraiment un formidable outil permettant d’itérer très vite sur des phases qui prenaient auparavant des semaines.
 
 Résultat, la barrière à l'entrée pour produire du logiciel semble avoir chuté et ça se ressent dans l’opinion.
 Créer un outil serait désormais à la portée de toute personne qui a des idées.
 De notre point de vue, c’est un peu plus compliqué que cela.
 L’enjeu n’a en soit jamais été la réalisation du code, mais plutôt la difficulté à savoir quoi produire, comment le produire et comment assurer sa phase de production dans le temps.
 
 Il est probable qu’à l’avenir les ingénieurs n’écrient plus une ligne de code, mais ils continueront à concevoir et à organiser la production de code logiciel. C’est un changement très profond, impactant de nombreuses structures comme Kapt.

H2 : Ce que 18 ans d’expérience comme artisans du numérique nous ont appris

Chez Kapt, nous avons accompagné des dizaines d'entreprises dans la conception et le développement de leurs applications ; et nous avons aussi eu l’expérience Start-Up autour de Side-projects : Kookooning, 10ThingsToSee, ...
 La leçon qu’on tire de ces expériences — bien avant l'IA — a toujours été la même : la vrai problématique ne s’est jamais limitée à la production de code.

Les projets qui échouent, n'échouent pas parce que les développeurs ne savent pas coder. Ils échouent parce que le besoin était mal posé, parce que les enjeux métier n'avaient pas été compris, parce que la solution technique répondait à la mauvaise question. Et même lorsque tout s’aligne d’un point de vue technico-fonctionnel, reste la grande question de l’accès au marché visé.

Pendant dix-huit ans, notre rôle a été autant d'analyser que de construire. D'écouter avant de proposer, d’aider à prendre les bonnes décisions techniques ... mais pas que. De dire parfois "ce n'est pas une application dont vous avez besoin" avant de sortir le premier wireframe.

L'IA ne change pas cette réalité. Elle la rend juste plus visible ... Ou plutôt elle va la rendre plus visible lorsque nous serons sortis de cette période d’euphorie.

De nouveaux rôles : manager d’agents IA ? Architecte de « bon sens »

Aujourd'hui, l'ingénieur (le développeur) qui se contente d'être un bon technicien voit son périmètre se réduire. Pas parce qu'il est moins bon mais parce que la « machine » est capable de réaliser des tâches pour lesquelles il fallait une équipe entière.

Ce qui émerge à la place, c'est un profil hybride que nous voyons se développer petit à petit :

Le spécificateur. Celui qui sait transformer une problématique floue en instructions claires et actionnables pour les agents. C'est un travail de rigueur et de langage plus proche du consultant que du codeur. C’est un rôle sur lequel nous avons déjà expérience et expertise.
 Sur ces tâches, l’IA est un vrai plus pour apporter de nouvelles idées (une phase de brainstorming) et pour rédiger plus rapidement, mais il est primordial que l’ingénieur relise et corrige chaque ligne, remette en question chaque choix.
 Sur le terrain nous observons souvent qu’il faut passer autant de temps à adapter qu’il n’en aurait fallu pour produire le document de zéro sans IA.

L'architecte de systèmes. Celui qui comprend comment organiser le code, comment sécuriser les interactions avec des services tiers, comment anticiper les défaillances. L'IA génère du code mais quelqu'un doit décider de la structure globale, du contenu des versions logicielles et de la finalité fonctionnelle. Sur cette tâche seule l’expérience permet de différencier un bon d’un mauvais choix technique. Le coût d’un logiciel n’est pas uniquement à considérer dans sa phase de création mais sur toute sa durée de vie. Et des mauvais choix dans la conception peuvent être extrêmement coûteux dans la phase d’exploitation.

Le garant de la qualité. Parce que les agents se trompent. Parce qu'un code généré sans relecture humaine peut introduire des erreurs invisibles et des failles silencieuses. Le regard critique de l'ingénieur n'a jamais été aussi précieux qu'aujourd'hui, précisément parce que le volume produit explose. Nous n’en sommes qu’au début mais nous sommes convaincus que nous observerons à l’avenir des erreurs logicielles dues à l’IA et aux conséquences potentiellement catastrophiques, car le processus de production logiciel n’aura pas été respecté.

Le responsable de l’évolutivité et de la maintenabilité. Comme nous allons itérer de plus en plus vite, il devient indispensable d’anticiper le support et l’évolution fonctionnelle d’un applicatif. Et c’est bien là, la crainte la plus forte autour du code généré par IA : Quid de sa capacité à s’étoffer sans effet de bord (bug) ? Quid de la maintenance ? Car l’expérience récente montre que les IA souffrent à faire évoluer une version. Et nous avons encore trop peu d’expérience sur un support logiciel qui sera géré par IA. Par contre, on sait qu’il est plus aisé de faire de la maintenance d’un code qu’on a conçu et contrôlé en amont.

L’illusion du « Tout le monde peut tout faire »

L'illusion du moment, c'est que l'IA démocratise la création de logiciels au point de rendre les experts inutiles. C'est une lecture superficielle.

Oui, un non-développeur peut aujourd'hui faire tourner un prototype en quelques heures. Mais transformer ce prototype en produit fiable, scalable, sécurisé, maintenable sur trois ans — c'est une autre histoire.

Arthur Mensch lui-même alerte sur le risque de « deskilling » : la perte progressive de compétences humaines liée à une dépendance excessive aux outils IA.

Nous partageons cette inquiétude. Pas pour nos ingénieurs seniors, qui ont les fondamentaux pour superviser les agents et l’expérience de la conception logicielle. Mais pour une génération de développeurs juniors qui risque d'apprendre à piloter sans jamais avoir conduit.
 Nous considérons qu’il est de notre responsabilité de former les futures générations pour qu’elles comprennent ce qui se passe « sous le capot », sans quoi il nous semble inéluctable que des accidents potentiellement grave se produirons.
 Qui ferait confiance à un système dont personne ne sait vraiment comment il fonctionne en interne et dont de surcroît personne n’a la capacité dans une équipe de le comprendre ?
 Croyez moi, je ne monterai pas dans ce TGV.

Une autre inquiétude concerne les signaux issus de notre démarche commerciale : « je peux faire autant avec mon abonnement mensuel pas cher qu’en payant votre prestation ». C’est une vision court-termiste dopée par l’envie de gain de rentabilité.
 Sur le long terme cette vision risque également de se heurter à une explosion de la bulle de l’IA et à une explosion du coût des token qui pourraient rendre les coûts de maintenance hors de contrôle.
 À ce titre nous sommes particulièrement vigilants sur la mise en place de processus automatisés dépendants d’agents d’IA dont nous ne savons pas quel sera leur coût demain : attention à la dépendance vis à vis de services dont nous savons dès aujourd’hui qu’ils ne sont pas rentables pour les entreprises qui les proposent. 

Ce numérique deviendrait jetable car LowCost et le risque est pluriel : on rompt un tissu économique d’expertise dont nous aurons besoin plus tard, on augmente considérablement l’impact environnemental, et ne parlons pas des aspects sociétaux ... Nous n’y croyons, ou du moins, nous n’en voulons pas.

Face à ces constats nous prônons une utilisation raisonnée de l’IA :

• Toujours s’assurer que le code produit correspond aux standards de qualité qui étaient la norme avant l’arrivée de l’AI

• S’assurer que le code est toujours compris par toute l’équipe de développement et maintenable « à la main » pour s’assurer qu’il sera toujours maintenable même dans un scénario dans lequel le coût des abonnements exploserai. Chaque ligne de code doit avoir été relue par un humain avant de passer en production.

• Maintenir coûte que coûte le process de développement qui assure la qualité d’un logiciel : courtes itérations, pair-coding, relecture du code, tests automatisés, validation en pré-production, ...

• S’interroger avant chaque prompt : est-il vraiment nécessaire ? Ne peut-il pas être remplacé par une recherche Qwant et quelques commandes dans un terminal ? Toujours garder en tête que chaque prompt représente une utilisation de ressources très conséquent avec des conséquences sur l’environnement extrêmement préocupant

• Utiliser l’IA comme un outil synonyme d’augmentation de la qualité avant d’augmentation de la quantité : c’est un formidable outil pour prototyper, comprendre plus rapidement des problématiques, avoir davantage de tests.

Notre conviction pour la suite et perspectives

Chez Kapt, nous n'avons pas attendu 2026 pour poser la question du problème avant celle de la solution rapide. C'est notre ADN depuis le début.

Ce que l'IA change pour nous, c'est la vitesse d'exécution ; et donc la capacité à tester, itérer, valider plus vite. Ce qu'elle ne change pas, c'est la nécessité de bien identifier l'enjeu, de comprendre le contexte métier, de choisir la bonne architecture logicielle.

L'ingénieur informatique de 2026 n'est pas moins ingénieur qu'avant. Nous dirions même « au contraire », il est plus stratège, davantage concepteur : peut-être moins artisan du code et plus architecte de solutions. Et dans cet équilibre, dix-huit ans d'expérience terrain restent la meilleure boussole.

Et sinon, si vous avez besoin d’expertise ...

Kapt accompagne les entreprises dans la conception et le développement de leurs applications depuis 2006. Si vous voulez explorer comment les outils IA peuvent accélérer vos projets — sans sacrifier la rigueur — parlons-