En dix-huit mois, le métier de développeur a changé de nature. Il n'a pas disparu, il s'est déplacé vers un poste qui n'existait pas : celui d'architecte agentique. Celui qui ne produit plus le logiciel mais qui construit et pilote l'équipe d'agents IA qui le produit. Voici ce que fait ce nouveau métier, d'où viennent ceux qui l'occupent et ce qu'il change pour les développeurs en place.
1. Le contrat où le mot « développement » avait disparu
Cet été, j'ai rédigé une trame de contrat de prestation pour un éditeur de logiciel accompagné en Pays de la Loire. Du classique en apparence : lots, livrables, recette, niveaux de service, propriété intellectuelle. En me relisant, j'ai buté sur un détail. Le mot "développement" n'y figurait presque plus.
L'objet du contrat était devenu double et indissociable. D'un côté, concevoir et maintenir un écosystème d'agents IA : les agents eux-mêmes, leurs règles, leurs référentiels de contexte, les contrôles automatiques. De l'autre, produire l'application au moyen de cet écosystème.
On n'achète plus des lignes de code. On achète un atelier de production et ce qu'il sort.
Une clause a demandé trois réécritures. Celle qui oblige le prestataire à réinvestir dans l'écosystème les enseignements de chaque cycle, de sorte que la capacité de production soit un actif du client et non un savoir-faire personnel du prestataire. Elle décrit un métier. Un métier qui n'a pas encore de nom stabilisé, appelons-le architecte agentique.
2. Comment le basculement s'est produit
J'ai écouté récemment le retour d'expérience du dirigeant d'un hébergeur cloud français. Soixante-dix développeurs, une infrastructure critique, aucune place pour l'approximation. Il était au départ franchement sceptique : « un perroquet statistique », disait-il.
Il a fallu convaincre. Une communication générale, propre et argumentée : aucun effet. Alors il s'est déplacé, bureau par bureau, responsable technique par responsable technique. Un jour, l'un d'eux lui répond qu'il a du travail, là, tout de suite. Il insiste, lance l'outil avec lui, repart téléphoner. À son retour :
Le machin vient d'exécuter mes cinq dernières semaines de boulot en deux heures. Et il a mieux codé que moi.
On peut tirer deux enseignements de cette phase et ce ne sont pas ceux qu'on attend.
La résistance est venue des développeurs eux-mêmes. Ceux qui ont bousculé le métier de tout le monde depuis trente ans ont été les plus réticents. C'est humain : on accepte mal de voir bouger ce qu'on maîtrise, et il y avait une inquiétude très légitime.
Ça ne se décrète pas. Aucune note de service n'a produit le moindre effet. Ce qui a fonctionné, c'est de s'asseoir à côté de quelqu'un et de lui faire vivre l'expérience une fois.
Un point à noter tout de suite, parce qu'il désamorce l'angoisse habituelle : cette transformation n'a donné lieu à aucun plan social. Environ 2 % de départs volontaires et les recrutements se poursuivent. Ce qui a changé, c'est le contenu du travail qui s'est déplacé.
3. Ce que fait réellement un architecte agentique
Le retournement est là et il est moins réjouissant qu'il n'y paraît.
Un développeur qui travaille avec des agents demande un programme, le reçoit, l'essaie, constate que ce n'est pas tout à fait ça, redemande une correction. Qu'a-t-il fait ? Il a confié la partie gratifiante qui est de produire et s'est gardé la vérification.
D'où le déplacement du métier vers l'amont et l'aval : décrire précisément ce qu'on veut, puis contrôler ce qui sort. Entre les deux, la machine travaille. Ce n'est plus un poste de production, c'est un poste d'encadrement, d'une équipe en effet très particulière : rapide, docile, inlassable, sans mémoire d'un jour sur l'autre et sans aucun jugement de contexte. Un stagiaire d'élite qui aurait tout lu et ne comprendrait rien à votre entreprise.
Concrètement, l'architecte agentique produit 4 choses et aucune n'est du code.
| Ce qu'il produit | Équivalent humain | Contenu |
|---|---|---|
| Définition d'agent | Fiche de poste | Finalité, périmètre, entrées et sorties, modèle utilisé, budget, garde-fous |
| Référentiel de contexte | Règlement intérieur et documentation | Conventions, architecture, vocabulaire métier, pièges connus, décisions passées |
| Orchestration | Organigramme et circuit de validation | Qui déclenche qui, dans quel ordre, avec quels points d'arrêt |
| Garde-fous | Délégations de signature | Ce que chaque agent peut toucher, ce qui reste interdit, qui valide quoi |
Une équipe d'agents ne monte pas en compétence comme une équipe humaine : elle ne se souvient de rien. On ne la forme pas mais on écrit son référentiel.
C'est le cœur du métier et son critère de qualité. Chaque correction manuelle répétée est le symptôme d'une règle manquante. Le bon architecte agentique n'est pas celui qui corrige vite. C'est celui qui, au bout de trois corrections identiques, écrit la règle qui supprime l'irritant voir même qui anticipe l'erreur ou le flou.
4. L'équipe qu'il monte : 8 rôles, 8 périmètres
Le réflexe naturel consiste à créer un agent par technologie. C'est une erreur. Le bon découpage est celui de n'importe quelle équipe humaine bien organisée : un agent par responsabilité séparable.
| l'agent | Sa mission | Ce qu'il n'a pas le droit de faire |
|---|---|---|
| Le cadreur | Il transforme une demande métier en spécification testable, avec des critères d'acceptation explicites. | Décider de la priorité ou du périmètre fonctionnel |
| L'architecte | Il découpe le travail, identifie les fichiers impactés et pose le plan. | Écrire du code |
| L'implémenteur | Il écrit le code, sur une branche isolée, strictement dans le périmètre du plan. | Sortir des fichiers prévus, ni écrire ses propres tests |
| Le testeur | Il écrit les tests à partir des critères d'acceptation, sans voir l'implémentation. | Modifier le code pour faire passer un test |
| Le relecteur | Il fait une revue critique portant sur ces critères : la sécurité, l'étanchéité entre clients, les régressions, les conventions. | Valider la mise en production |
| Le documentaliste | Il rédige les notes de version, il produit la documentation technique, il génère le journal des changements. | Toucher au code |
| L'exploitant | Il surveille et écoute les erreurs remontées du terrain, il les qualifie, il crée le ticket enrichi. | Déployer ou écrire en production |
| Le curateur | Il repère les corrections manuelles récurrentes et propose une nouvelle règle. | Modifier le référentiel sans validation humaine |
Deux séparations ne se négocient pas.
Celui qui écrit ne teste pas. Si vous demandez à un agent de produire son travail et de le vérifier, il vous dira que tout va bien. Ce n'est pas de la malhonnêteté, c'est mécanique : il optimise ce que vous mesurez. C'est le mode de défaillance numéro un.
Celui qui relit ne valide pas. La mise en production reste un acte humain, nominatif, tracé. Le contrat que j'évoquais en fait même une condition de la responsabilité du prestataire : il répond du livrable quelle que soit la part générée par IA.
5. Avec quoi il travaille
Prenons un cas réel qui concerne énormément de domaines : une société d'une quinzaine de personnes qui édite une solution SaaS multi-tenant, un produit utilisé quotidiennement par des établissements clients.
| Brique | Rôle dans la chaîne | Traduction |
|---|---|---|
| Claude | Les agents eux-mêmes, chacun décrit par son fichier de définition | L'équipe, et ses fiches de poste |
| Jira | Le poste de commande. On assigne un ticket à un agent comme à un collaborateur. C'est possible depuis juin 2026. | Le tableau de répartition du travail |
| Confluence | La mémoire de l'organisation : spécifications, décisions d'architecture, vocabulaire métier, rendue lisible aux agents | Le classeur de procédures |
| Sentry | Les remontées du terrain. Une erreur survient chez un client, Sentry la capte, analyse la cause racine, et l'agent propose un correctif | La boîte à réclamations branchée sur l'atelier |
| Github | Le lieu où l'humain reprend la main : revue, contrôles automatiques bloquants, validation | Le contrôle qualité avant expédition |
| MCP | Le protocole standard qui branche les agents sur les outils de l'entreprise | La prise de courant normalisée |
Le circuit tient en une phrase. Un utilisateur rencontre un bug, Sentry le capte et le qualifie, un ticket Jira est créé, un agent le prend en charge en lisant le contexte dans Confluence, travaille dans un environnement isolé, ouvre une proposition de correction et un humain décide si ça part en production.
Aucune de ces briques n'est exotique et d'ailleurs 3 étaient déjà là avant l'IA. C'est précisément l'intérêt : l'agentique ne remplace pas votre organisation, elle s'y branche. Encore faut-il que l'organisation existe.
6. Ce qu'il fait faire et que personne ne faisait
C'est la partie qui distingue un architecte agentique d'un développeur bien outillé. Sa formule : l'IA n'est pas humaine donc il faut lui demander des tâches inhumaines.
Préparer une réunion de trente personnes. Cet hébergeur a un logiciel central sur lequel une trentaine de personnes interviennent chaque semaine. La réunion de synchronisation du lundi tournait à vide. Plutôt que de demander du code, il a demandé la préparation de la réunion : lire toutes les branches de travail, comparer les résultats des tests, repérer où les contrôles échouent en série, relever les discussions qui s'enveniment, identifier les décisions d'architecture en attente. Trois à quatre jours de travail humain. Vingt minutes de machine. Et un ordre du jour réellement qualifié.
Attaquer la dette technique. Toutes les entreprises ont ces dossiers sous le tapis (ce que j'appelle le poids de l'histoire) : le module qu'il faudrait refaire, la bibliothèque obsolète qu'on ne remplace pas parce que « ça va tout casser ». Avant, c'était deux semaines de travail minimum avec un fort risque d'enlisement. Donc on n'essayait pas. Aujourd'hui : « implémente cette alternative de bout en bout, mesure les performances, on en reparle demain. » Parfois le résultat est trois fois plus rapide. Parfois c'est un échec et on l'a su pour le coût d'une nuit de calcul. Cet hébergeur s'est fixé un objectif que personne n'aurait osé formuler il y a deux ans : ne plus faire tourner, fin 2026, que du code produit dans l'année.
Tester sa propre sécurité en continu. Chaque livraison de code subit un test d'intrusion automatique. Encore mieux : plusieurs modèles d'IA concurrents sont lancés en permanence contre leurs propres systèmes. Le raisonnement est imparable : si votre IA ne trouve pas la faille, celle de l'attaquant en face ne la trouvera probablement pas non plus. Ils ont ainsi découvert plusieurs vulnérabilités réelles, certes jamais exploitées mais bien présentes. C'est un audit continu, pour un coût sans commune mesure avec un audit annuel.
Je me dois d'être honnête, parce que les promesses uniformes m'agacent : les gains sont très inégaux. Sur des tâches courantes et bien documentées, ils sont spectaculaires. Sur des sujets pointus où il existe peu de références publiques, ils sont modestes et parfois même négatifs. Méfiez-vous de quiconque annonce un multiplicateur valable partout.
7. Comment l'architecte agentique pilote ?
Forcément, les jours-homme ne veulent plus dire grand-chose. Ce qu'un architecte agentique regarde à la place :
| Indicateur | Ce qu'il révèle |
|---|---|
| Part des livraisons agentiques acceptées sans reprise | La qualité du référentiel : pas celle du modèle IA |
| Nombre de reprises par cause récurrente | Les règles qui manquent encore |
| Coût IA et hébergement par fonctionnalité livrée | La dérive économique et ça va vite ! Un agent mal cadré tourne en boucle et ça se paie |
| Délai entre la demande et la mise en production (timetomarket) | Le gain réel, hors effet d'annonce |
| Délai estimé de reprise par un tiers | Le niveau de dépendance |
Et du côté des rituels, rien de révolutionnaire :
- Une revue mensuelle du portefeuille d'agents : lesquels coûtent cher, lesquels ne servent plus,
- Quelles règles ajouter,
- Une revue trimestrielle des accès,
- Un suivi continu des budgets.
Reste le sujet du coût, complexe et systématiquement mal posé. Oui, faire tourner des agents consomme et coute de l'argent. Mais l'essentiel de la dépense ne va pas à l'écriture du code : elle va à tout ce qui l'encadre : les tests, les contrôles, les vérifications. C'est exactement là qu'est la valeur. Comme le résume le dirigeant cité plus haut : sans ce harnais, vous produisez du code que vous ne comprenez pas, dans un système que vous ne comprenez pas et vous essayez de rattraper après. C'est ce qui sépare les entreprises qui tirent un bénéfice réel de l'IA de celles qui n'en tirent rien.
8. Sa relation avec les développeurs en place
Le sujet qui fâche et le plus délicat. Et celui qui est très mal abordé.
Ce n'est pas un poste hiérarchique. L'architecte agentique n'est pas le chef des développeurs. Il écrit le cadre dans lequel tout le monde travaille : les règles, les contrôles, les circuits de validation. Si vous le positionnez en surplomb, vous perdez l'équipe et le cadre ne sera pas appliqué. Il doit rester praticien : celui qui écrit la règle est celui qui a subi l'irritant.
Il vient des profils expérimentés, pas des juniors. C'est le constat qui prend l'intuition à contre-pied. On imaginait que l'IA nivellerait les compétences. Elle fait complètement l'inverse : elle démultiplie l'expérience. Les profils chevronnés qui encadraient des équipes et n'avaient plus le temps de produire s'y sont remis. Plusieurs disent n'avoir jamais aussi bien travaillé de leur carrière, parce qu'ils peuvent enfin appliquer les bonnes pratiques qu'on sacrifiait toujours faute de temps (vous savez, les tests qui passent à la trappe). C'est logique : le métier devient savoir ce qu'on veut, reconnaître du bon travail, décider. Exactement ce que l'expérience donne.
Le développeur ne disparaît pas, sa compétence critique se déplace. Elle passe de « savoir écrire » à « savoir juger ». Relire du code qu'on n'a pas écrit, repérer ce qui ne va pas, dire non. C'est en effet un travail moins gratifiant à court terme, plus exigeant sur le fond. Il demande d'ailleurs d'être reconnu comme tel : si la revue reste considérée comme une corvée entre deux vraies tâches, elle sera mal faite et c'est le seul rempart de la chaîne.
La formation des débutants est le vrai problème non résolu. On apprenait à coder en codant mal, puis en se faisant reprendre. Du coup, si les agents écrivent le code courant, par où passe l'apprentissage ? Personne n'a de réponse convaincante aujourd'hui et je me méfie de ceux qui prétendent le contraire. C'est un sujet à mettre sur la table avec votre prestataire ou votre équipe et qui n'est pas à ignorer.
Sur les outils, enfin, lâchez du lest. Le dirigeant cité plus haut a d'abord voulu imposer un outil unique à toute l'entreprise. Il y a renoncé : le marché évolue trop vite pour qu'un choix tienne un an. Il a mis une ligne « IA » dans les notes de frais, autorisé chacun à acheter ce qu'il veut, interdit les abonnements annuels et organisé un temps d'échange régulier.
Ce n'est pas contradictoire avec tout ce qui précède et la nuance est le point de gouvernance de cet article. Ce qui se normalise, c'est le processus : qui valide, quels contrôles sont bloquants, quelles données ont le droit de sortir. C'est durable et c'est ce qui vous protège. Ce qui reste libre, c'est l'outil individuel et de toute façon, il sera périmé dans 6 mois. L'erreur classique consiste à faire l'inverse : verrouiller l'outil pour 3 ans par contrat et laisser le processus au hasard.
9. Faire cohabiter les agents et les développeurs
C'est la question que tout dirigeant finit par poser. La réponse est oui mais pas au sens où on l'entend généralement. Ce qui cohabite durablement, ce sont des humains et des agents sous un même cadre. Pas deux façons de travailler côte à côte dans le même code, là c'est la catastrophe annoncée.
Le point dur est le suivant. L'écosystème fonctionne parce que le référentiel de contexte décrit le système réel. Un développeur qui travaille à la main sans alimenter ce référentiel crée une divergence : les agents continuent alors de produire un code cohérent avec une description périmée. La dérive est silencieuse et on la découvre tard.
Reste à choisir comment répartir le travail. Trois modèles existent, et aucun n'est meilleur dans l'absolu.
| Modèle | Critère de partage | Ce qui va bien | Ce qui coince |
|---|---|---|---|
| Par zones | Une frontière dans le code : agentique sur les intégrations, les écrans, les tests, les migrations et humain sur le cœur métier et le bas niveau | Lisible, mesurable, sans conflit quotidien. C'est le choix de l'hébergeur cité plus haut : le noyau système et les équipements réseau restent humains, le reste bascule | La frontière se déplace tous les 3 à 4 mois. Et selon la manière dont on la présente, la zone humaine devient un sanctuaire ou un placard |
| Par étape | Pas de zone réservée : les agents produisent, les humains cadrent et relisent, partout | L'équipe reste une, rien à arbitrer en permanence | C'est le modèle qui retire vraiment le plaisir de produire. Risque de départs, et la relecture devient un goulot d'étranglement |
| Par coût de l'erreur | Réversible et testable, c'est agentique. Irréversible (schéma de données, facturation, sécurité, migration) c'est piloté humainement de bout en bout | Le critère le plus rationnel, et le plus simple à expliquer en comité de direction | Suppose une cartographie des risques que peu d'équipes possèdent réellement |
Quel que soit le modèle retenu, 5 conditions font tenir l'ensemble.
- Un seul référentiel, opposable à tous. La convention qui vaut pour l'agent vaut pour l'humain. Un développeur qui contourne une règle rend le référentiel menteur et tous les agents propagent ensuite son écart. C'est la condition : les 4 suivantes en découlent.
- Les mêmes contrôles bloquants pour tout le monde. Aucune voie rapide pour le code écrit à la main, sinon il devient la zone non testée du système.
- La relecture s'applique aussi au code humain. Le biais inverse est réel : on épluche la production de l'IA et on fait confiance au collègue.
- Traçabilité de l'origine de chaque livraison. Sans elle, impossible de mesurer où ça fonctionne et où ça dérape.
- Toute correction manuelle remonte dans le référentiel. Sinon vous payez deux fois : la correction, puis indéfiniment la récurrence.
Le vrai risque, cependant, n'est pas technique. Il est humain, et il tient en deux mots : deux vitesses.
Celui qui travaille à la main sur le cœur métier livre cinq fois moins vite que celui qui pilote des agents sur les intégrations. Si vos indicateurs ne font pas la distinction, le premier passe pour lent. C'est le moyen le plus sûr de perdre exactement les profils dont vous avez le plus besoin, ceux qui tiennent la partie du système que personne d'autre ne sait reprendre.
10. Ce que ça change pour le Dirigeant ou le Décideur
Si vous faites développer un logiciel, la dépendance n'a pas disparu : elle a déménagé. Elle portait sur une personne qui connaissait votre code. Elle porte désormais sur un système que personne d'autre ne sait piloter et c'est moins visible.
Quatre questions à poser à votre prochaine réunion. Aucune ne demande de compétence technique.
- Qui est propriétaire des agents, des instructions et des règles ? Si le contrat ne cède que le code, vous avez le produit mais plus le moyen de le faire évoluer.
- Qui valide avant la mise en production et est-ce tracé ? Un nom, pas une intention.
- Combien de temps faudrait-il à un autre prestataire pour reprendre la main ? Si personne n'a la réponse, c'est la réponse.
- Mes données réelles passent-elles dans ces outils et à quelles conditions de non-réutilisation ?
Si vous êtes prestataire ou indépendant, et je m'inclus dans le lot, vos clients vont réclamer la propriété de votre cadre, pas seulement du livrable. Votre responsabilité ne se diluera pas dans l'outil : « c'est l'IA qui l'a écrit » n'est une excuse nulle part. Et votre valeur se déplace vers ce qui ne s'automatise pas : comprendre le métier du client, arbitrer, dire non, porter la responsabilité.
Le développeur n'est pas mort. Il a changé de niveau : il ne produit plus le résultat, il produit et garantit le moyen de l'obtenir. C'est un métier plus exigeant, pas moins. Il demande de la rigueur d'organisation là où l'on attendait de la virtuosité technique.
Il se trouve simplement que le métier de développeur est passé le premier. En Sarthe, en Maine-et-Loire ou en Vendée, d'autres métiers suivent déjà le même chemin : Community manager, Commercial sédentaire, etc.
Vous faites développer un logiciel métier ou une application SaaS ? Un état des lieux tient en une demi-journée : qui produit quoi, avec quels outils, qui valide et ce qui se passerait si votre prestataire s'arrêtait demain. Un premier échange de 30 minutes suffit généralement à savoir si le sujet est ouvert chez vous.
Réservez en ligne votre créneau pour un appel découverte de 30mn gratuit et sans engagement avec un DSI Externalisé à Temps Partagé.