Agentic AI: How AI Agents Transformed My Work as a Software Engineer and CEO

Introduction

Bonjour à tous, je m'appelle Simon Harrer. J'ai fait une thèse sur les systèmes distribués, puis j'ai passé sept ans chez INNOQ comme architecte logiciel et consultant. Depuis 2025, je suis Co-Founder et CEO d'Entropy Data, un spin-off d'INNOQ.

À côté de ça, j'ai coécrit le livre « Java by Comparison » et cotraduit le livre « Data Mesh » en allemand. Je suis aussi co-mainteneur des outils open source mob.sh et Data Contract CLI. Et je siège au Technical Steering Committee du projet BITOL de la Linux Foundation, qui porte les standards de Data Contracts et de produits de données.

Aujourd'hui, je voudrais vous parler de la façon dont les agents IA ont complètement transformé mon travail, aussi bien comme développeur que comme CEO.

Mon moment IA personnel

C'était en avril 2025. J'étais dans un train pour Berlin avec André Deuerling. Grâce à la Deutsche Bahn, on a fini avec plus de deux heures de retard. Du coup, on s'est installés au wagon-restaurant et on a enchaîné les bières. André utilisait déjà Claude Code, alors on a décidé d'essayer ensemble.

La mission : construire un service Spring Boot qui se connecte à une base MariaDB, lit tous les schémas, tables et colonnes, et pousse ces métadonnées dans l'API de notre produit. La règle était simple : zéro ligne de code écrite à la main. Uniquement du prompt.

On y a passé environ deux heures. On relisait ce qu'il générait, on relançait des prompts, on revoyait des décisions d'architecture. Puis on a récupéré les clés d'API, configuré le tout à la main, lancé le service, et ça a marché. Tout simplement.

C'était mon moment IA personnel. Le moment où j'ai compris que quelque chose de fondamental venait de basculer.

Qu'est-ce qu'un agent ?

Alors, c'est quoi un agent ? C'est en fait très simple : un LLM qui utilise des outils, en boucle.

Claude Code, c'est exactement ça. Il y a un LLM qui tourne en arrière-plan et qui a accès à une panoplie d'outils : il peut passer des appels en CLI, lire et écrire des fichiers, faire des recherches sur internet, lancer des tests, compiler du code. Même la mémoire n'est qu'un outil, en gros une todo list à laquelle l'agent accède via une interface d'outil.

Voilà tout le concept. Un LLM qui utilise des outils, en boucle. Et pourtant, vous allez le voir, ce concept tout simple a changé complètement ma façon de travailler.

Les débuts

Après cette expérience, je me suis mis à utiliser Claude Code de plus en plus. Je dois être honnête : au début, tout n'était pas génial. Il m'est arrivé de jeter entièrement le code généré et de repartir en codant à la main. Mais j'ai continué à essayer.

J'ai pris l'abonnement à 20 $ par mois. Ça ressemblait à un abonnement Netflix : engagement faible, potentiel énorme.

Le vrai tournant : les modèles Opus

Puis Opus 4.5 est arrivé, en novembre 2025. Là, c'était vraiment le tournant.

Regardez le benchmark METR. Il mesure la durée des tâches qu'un LLM arrive à mener à bien dans au moins 50 % des cas. GPT-5.1 et Codex Max se situent autour de trois heures. Opus 4.5 est monté à environ cinq heures, un bond énorme. La courbe est exponentielle.

Ensuite Opus 4.6 est sorti en janvier et a encore à peu près doublé ce chiffre, à une douzaine d'heures. Cette différence, on la sent vraiment quand on travaille avec. Des tâches lourdes et complexes que l'IA n'arrivait tout simplement pas à traiter avant sont désormais à portée.

La durée des tâches double tous les six mois

La tendance est nette : la durée des tâches double environ tous les six mois. Ce qui semblait impossible hier devient très vite la nouvelle normalité.

Dès que j'ai vu ça, je suis passé immédiatement à l'offre à 100 $ par mois. C'est cinq fois plus de dépense, et il n'y a pas eu l'ombre d'un débat en interne. La valeur sautait aux yeux.

Ce pour quoi j'utilise les agents

Passons aux cas d'usage concrets. J'utilise les agents pour :

• Développer des fonctionnalités avec leurs tests, le pain quotidien.
• Tester l'UX avec le serveur MCP Playwright, des tests automatisés dans le navigateur.
• Provisionner l'infrastructure avec Terraform : je n'ai plus jamais besoin de lire la doc Terraform.
• Optimiser les performances avec le serveur MCP Dash0, branché sur les logs, traces et métriques OpenTelemetry. Je peux dire « analyse mes performances, regarde le code, est-ce qu'on peut améliorer ça automatiquement ? », et il le fait.
• Implémenter des tickets via la CLI GitHub : l'agent lit le ticket et l'implémente.
• Générer le changelog à partir des commits git.
• Rédiger la documentation avec des captures d'écran automatisées : plus besoin de recruter quelqu'un pour écrire les manuels utilisateur.
• Faire des tests exploratoires : chercher des bugs dans l'application en production, y compris les bugs visuels et les écarts avec le design guide.
• Rédiger des brevets : j'ai écrit un brevet avec un collègue en m'appuyant sur l'IA. On n'aurait tout simplement pas eu les moyens de payer un conseil en propriété industrielle.
• Relire des contrats pour les clients grands comptes.

L'éventail est énorme. Et il s'élargit chaque semaine.

Comment mon travail a changé

Je n'écris plus jamais de message de commit git. Je dis juste « claude push » et il rédige le message à partir du contexte. Je n'écris plus de code non plus : je laisse le code s'écrire, puis je le relis. Beaucoup. C'est devenu mon activité principale, donner des instructions et relire.

Et soyons honnêtes : je ne relis plus tout. Je relis de façon sélective, en fonction du risque. C'est un compromis, et j'en ai conscience. Mais je vous spoile la suite : sans ce compromis, le logiciel n'existerait tout simplement pas. Ça aurait pris trop de temps.

Je travaille aussi avec deux ou trois terminaux en parallèle, parce qu'il y a forcément des temps d'attente pendant que l'IA travaille. Pendant qu'un agent avance sur une tâche, je relis ou je prompte dans un autre.

Le mode YOLO

Depuis trois ou quatre semaines, j'ai activé le mode YOLO. Autrement dit, Claude peut faire tout ce qu'il veut, sauf ce qui touche à la production.

Avant ça, j'avais le modèle de sécurité activé, celui où Claude demande la permission avant d'exécuter une commande. Sauf que j'ai développé ce que j'appelle la « fatigue de l'approbation ». L'IA s'arrêtait sans arrêt pour poser des questions triviales du genre « est-ce que je peux lancer cette commande find ? ». Je me suis surpris à appuyer sur Entrée sans même lire la question. À ce stade, le modèle de sécurité relève du théâtre, pas de la sécurité.

Alors j'ai inversé la logique : laisser l'IA travailler en autonomie jusqu'à ce qu'elle estime la tâche terminée. Je n'ai pas envie de revenir en arrière. J'aimerais quand même un meilleur modèle de sécurité, la sécurité n'est pas un sujet secondaire, mais c'est aujourd'hui le meilleur compromis en termes de productivité.

Faisons une pause

Prenons un instant de recul. Ça fait beaucoup de changements, et ils sont allés très vite.

J'ai travaillé de la même façon pendant dix ans. Puis, en onze mois seulement, d'avril 2025 à mars 2026, tout a changé. Je construis toujours un produit logiciel. Mais la façon dont ce logiciel est fabriqué n'a plus rien à voir.

Et ce n'est « qu'un » LLM qui utilise des outils, en boucle. Rien de plus. Et pourtant, ça a tout changé.

Sous-agents et équipes d'agents

Mais ça ne s'arrête pas là. L'étape suivante, ce sont les sous-agents : l'agent principal lance des agents plus petits pour des tâches de recherche. Par exemple, « trouve la meilleure façon d'instrumenter cette bibliothèque ». Le sous-agent part, fait sa recherche, et renvoie les résultats. Ça protège le contexte de l'agent principal du bruit inutile. Une partie se fait déjà automatiquement, avec le researcher intégré à Claude par exemple.

Au-delà, il y a les équipes d'agents : vous montez une équipe avec un architecte qui critique la conception, un profil UX qui critique l'interface, et un codeur qui construit. Vous les laissez échanger et itérer. J'ai essayé une ou deux fois. C'est encore trop tôt pour juger, et ça consomme nettement plus de tokens. Mais la direction est claire.

Le passage au cloud

La suite logique, c'est le cloud. Tout ce que je viens de décrire se passait sur mon MacBook, en local. Mais il existe maintenant une interface web. Je peux lancer des tâches depuis mon téléphone ou mon navigateur. Je peux lancer du travail avant d'aller dormir, en déplacement, ou même juste avant une keynote comme celle-ci.

L'agent travaille, et quand il a fini, il m'affiche quelque chose comme « 69 lignes ajoutées, 5 supprimées ». Je peux relire les modifications et ouvrir une pull request. L'agent travaille pendant que je ne suis pas à mon bureau.

Des agents déclenchés par les événements

Le déclencheur change lui aussi. Ce n'est plus seulement un humain qui dit « fais ceci ». Quand une alerte remonte via nos outils d'observabilité, un agent peut l'analyser automatiquement. Si c'est une exception, par exemple quelqu'un qui a utilisé dans un template une variable qui n'existe pas, l'agent peut créer un correctif tout seul et ouvrir une pull request. Nous, on clique juste sur merge.

Même chose pour les pipelines CI en échec, les vérifications post-commit (par exemple s'assurer que la documentation reste synchronisée avec le code), ou des cron jobs quotidiens ou hebdomadaires confiés à des agents. Tout ça tourne dans des workflows CI/CD GitHub ou GitLab tout ce qu'il y a de plus standard. Les agents deviennent une brique de l'infrastructure.

Spec-driven development : les agents travaillent pendant que vous dormez

Je me suis inspiré d'une offre d'emploi d'Anthropic, celle à 500 000 $ par an qui exigeait un « usage maximal de Claude ». Ça m'a fait réfléchir : comment faire travailler des agents même quand, moi, je ne travaille pas ?

La réponse, c'est le spec-driven development avec un outil qui s'appelle AutoClaude. C'est en gros un tableau Kanban : j'y dépose des tâches, je les décris (l'IA peut même m'aider à rédiger les descriptions), je fixe une limite de trois travaux en cours, et je laisse tourner la nuit. J'ai dû passer à l'offre à 200 €, parce que les limites de tokens de l'offre en dessous ne suffisaient plus.

Techniquement, il clone le dépôt, crée une branche via git worktree pour chaque tâche, et travaille en local. Je lance dix tâches avant d'aller me coucher et je les relis le matin.

Le workflow, c'est : planifier, puis coder, puis une boucle de QA, puis une revue par l'IA, et enfin une revue humaine. L'outil génère une spec, produit un compte rendu de QA, et peut même aider à définir la roadmap produit par analyse concurrentielle et identification des fonctionnalités manquantes.

Le point essentiel : l'agent travaille pendant que je dors, et je reviens le matin pour relire les résultats.

Le compromis sur la qualité

Je veux être transparent sur un point important : la qualité n'est pas aussi élevée que quand je codais tout à la main. L'architecture est moins propre. Le nommage pourrait être meilleur. Le code est moins fini.

Mais voilà le fond du sujet : sans l'IA, ce logiciel n'existerait pas. Si j'avais tenu à tout faire au niveau d'exigence d'avant, on n'aurait jamais livré.

Si vous travaillez dans un domaine où la perfection est indispensable, des commandes d'avion ou des systèmes de sécurité ferroviaire, ce compromis ne tient sans doute pas. Mais pour du logiciel B2B ? C'est largement acceptable. Le gain de vitesse pèse bien plus lourd que l'écart de qualité.

Le point de vue du CEO : le budget IA

Changeons de casquette et passons à mon rôle de CEO. Voici comment notre budget IA par personne et par mois a évolué :

• 2025 : 20 € par personne et par mois
• 2026 : 100 € (en réalité déjà 200)
• 2027 : 1 000 € (estimation prudente)
• 2028 : 2 000 €

Dans la Silicon Valley, les entreprises calculent déjà des budgets IA à 10 ou 20 % du salaire. Ça revient à peu près à 20 000 € par an. Elles sont déjà là où je nous imagine en 2028.

L'IDE est-il mort ?

Nous ne renouvellerons pas nos licences IntelliJ. On avait pourtant une remise startup de 50 %. Mais je n'en vois plus la valeur. Je n'utilise plus IntelliJ que par habitude et pour relire des modifications de code. Pourquoi payer 1 000 € par an rien que pour ça ? Claude Code coûte 100 € par mois et c'est un bien meilleur investissement. C'est une question de coût d'opportunité. Et comme la Community Edition n'est plus une option viable pour un usage commercial, le calcul est encore plus limpide.

J'ai vu récemment un post LinkedIn de Ralf Müller qui affirmait que « The IDE Is Dead ». Il avait 27 likes mais plus de 53 commentaires (mise à jour du 12 mars 2026 : 113 commentaires), tout le monde défendant son IntelliJ parce qu'il l'adore. C'est un sujet émotionnel. Les gens sont attachés à leurs outils. Mais l'attachement ne devrait pas dicter les décisions budgétaires.

6 engineers = 60

On peut construire une startup SaaS B2B avec seulement six engineers. Ces six-là accomplissent ce qui en demandait soixante auparavant. Nous n'allons pas recruter beaucoup plus de monde. Les entreprises vont voir leur profit par employé grimper très fort. Le passage à l'échelle se fait par les coûts d'IA, pas par les effectifs.

Beaucoup de petites structures vont naître de ce mouvement. Nous livrons des fonctionnalités à une vitesse folle parce que nos engineers sont des product engineers, pas seulement des développeurs. Ils prennent des décisions produit rapidement. Ils comprennent le client. C'est là le vrai facteur différenciant : la capacité à déléguer les décisions produit à des personnes qui comprennent vraiment la technique et le client.

Construire ne coûte presque plus rien. Le vrai goulot d'étranglement, c'est de décider quoi construire, et de déléguer la responsabilité de ces décisions.

Qui nous recrutons

Nous recrutons de façon très sélective. Nos profils préférés sont :

• Les juniors : ils sont AI-native. Ils n'ont pas à désapprendre d'anciennes façons de faire. Ils ont grandi avec ces outils.
• Les principals : ils apportent le sens du produit, une compréhension fine du client et une vision stratégique. Ils valent l'investissement.
• Les seniors : en troisième choix. Ce n'est pas un mauvais profil, mais dans un monde AI-native, les deux autres apportent davantage.

L'opportunité la plus grande : les données d'entreprise

Mais les opportunités sont encore plus grandes ailleurs. L'agentic coding n'utilise que du code, des données de télémétrie et des tickets. Nous, les développeurs, vivons dans notre monde de code. Les gens du métier, eux, pensent en données. Ce qui devient vraiment passionnant, c'est quand on ajoute les données d'entreprise à l'équation.

Imaginez la question : « pourquoi les coûts énergétiques de la production ont-ils davantage fluctué ces douze derniers mois ? » (source : BARC) Un agent pourrait répondre à cette question en une heure. Il analyserait les données de production, les croiserait avec les prix de l'énergie, regarderait les plannings, et en tirerait une synthèse.

Souvenez-vous : un agent, c'est toujours juste un LLM qui utilise des outils, en boucle. Il peut répondre à des questions métier, pas seulement à des questions de code. Sauf que là, il travaille avec des données d'entreprise : données clients, données de santé, données financières, données opérationnelles.

Grâce aux outils, les agents peuvent aller chercher les données d'entreprise et en faire tout ce qu'ils veulent. C'est là que se trouve la vraie valeur pour la plupart des organisations.

La couche de gouvernance

Une armée d'agents arrive, et tous veulent accéder aux données d'entreprise. Quatre-vingts pour cent des collaborateurs le demandent. Mais il reste de vrais défis à résoudre :

• Le contrôle d'accès : qui a le droit d'accéder à quoi ?
• La découvrabilité : comment les agents trouvent-ils les bonnes données ?
• La sémantique des données : qu'est-ce que ces données veulent vraiment dire ?
• Les conditions d'utilisation : dans quel cadre ces données peuvent-elles être exploitées ?
• La qualité des données : à quel point sont-elles fiables ?
• Les SLA et les garanties : quelles performances et quelle disponibilité peut-on attendre ?

Il vous faut une couche de gouvernance entre les agents d'un côté, et les données et API de l'entreprise de l'autre. Sans elle, soit vous bloquez complètement les agents, soit vous fabriquez un cauchemar de sécurité et de conformité.

Démo en direct : quand les agents rencontrent les données d'entreprise

Je vous montre une démo en direct. Je demande à l'agent : « quels tickets de support reviennent le plus souvent ? »

L'agent cherche parmi les données disponibles et trouve une table pertinente dans une base. Il demande un accès, qui est approuvé automatiquement puisqu'il s'agit de données non sensibles. Puis il lance des requêtes SQL et analyse les données sous plusieurs angles.

Le résultat : les incidents représentent 40 % des tickets, suivis des demandes, puis des problèmes, et enfin des changements. À partir de là, l'agent pourrait continuer : creuser davantage, croiser avec d'autres sources de données, ou formuler des recommandations. C'est la couche de gouvernance qui rend tout cela possible, de façon sûre et maîtrisée.

Un appel aux architectes

Les architectes. Vous.

C'est avant tout un problème d'architecture logicielle. Il touche aux objectifs de qualité, à l'intégration des composants, à la gestion des interfaces, aux frontières de sécurité et à l'organisation des équipes. C'est probablement le chantier d'architecture le plus important des prochaines années.

Les agents, au-dessus, ne valent que ce que vaut cette couche de gouvernance en dessous d'eux. Sans une vraie Data Governance, soit les agents ne peuvent pas travailler, soit on ne peut pas leur faire confiance.

Mon appel : s'il existe une initiative dans votre organisation pour construire cette couche, impliquez-vous. Contribuez à lui donner sa forme. C'est elle qui déterminera la suite. Parce que les agents arrivent : c'est tout simplement trop puissant et trop utile pour que ça n'arrive pas.