La fin du développeur d'applications : Pourquoi la prochaine décennie appartient aux bâtisseurs d'agents

L'histoire a cette drôle de manie de rimer, généralement juste au moment où l'on commence à se sentir à l'aise.

Imaginez la fin des années 90. Si vous saviez dompter le HTML et un peu de Perl ou de PHP pour en faire un site web fonctionnel, vous étiez un sorcier. Vous étiez un Ingénieur Web, et le monde vous appartenait. Vous construisiez les vitrines d'Internet.

Avance rapide jusqu'en 2009. L'iPhone venait d'ouvrir une brèche dans le monde. Soudain, plus personne ne se souciait autant de votre site web statique. L'énergie s'est déplacée vers l'Objective-C et le Java. Si vous étiez Ingénieur d'Applications Mobiles, vous écriviez le futur. Vous construisiez les outils que les gens transportaient dans leurs poches.

Maintenant, regardez 2024. L'air semble à nouveau raréfié et statique. Les app stores sont saturés ; le web est encombré. Mais sous la surface, un changement tectonique est en cours. Nous quittons l'ère de l'Interface pour entrer dans l'ère de l'Agent.

Dans la prochaine décennie, le titre le plus précieux ne sera pas "Développeur Full Stack" ou "Ingénieur iOS". Ce sera Ingénieur d'Agents IA (AI Agent Engineer).

Le nouveau changement tectonique

Ce n'est pas juste une autre guerre de frameworks ou un nouveau langage de programmation à apprendre. C'est un changement fondamental dans qui fait le travail.

Au cours des vingt dernières années, l'ingénierie logicielle consistait à construire des chemins clairs et déterministes sur lesquels les humains devaient cliquer. Vous construisiez un bouton ; l'humain cliquait dessus ; le code exécutait une fonction. L'humain était le cerveau ; le logiciel était le muscle.

Cette dynamique est en train de s'inverser.

Dans l'ère des Agents, le logiciel fournit le cerveau. Votre travail n'est plus de construire le bouton sur lequel l'humain doit cliquer. Votre travail est de construire l'employé numérique qui décide quand cliquer sur le bouton, ou mieux encore, qui comprend que le bouton n'est même pas nécessaire.

Je construis des produits depuis plus de dix ans, et je sens le sol bouger. Si vous êtes capable d'écrire un agent aujourd'hui — un agent qui vous sert, automatise votre flux de travail ou sert vos clients — vous avez le même effet de levier que ce gamin en 1999 qui venait d'apprendre à mettre une entreprise en ligne.

Mais voici la dure vérité : si vous refusez d'apprendre cela, si vous vous en tenez au codage purement déterministe, vous risquez de devenir l'équivalent numérique d'un typographe à l'ère de la publication assistée par ordinateur.

Démystifier la magie : Outils et Contexte

Quand les gens entendent "Agent IA", ils imaginent Skynet ou une architecture de réseau neuronal impossiblement complexe. Coupons court au bruit.

Construire un agent n'est pas de la magie. C'est de l'ingénierie. Et cela se résume à deux choses : Outils et Contexte.

J'ai constaté que la plupart des développeurs compliquent trop les choses. Ils pensent qu'ils doivent entraîner des modèles. Ce n'est pas le cas. Les modèles — Claude, GPT-4, Llama — sont assez intelligents. Votre travail est de leur donner des mains et une mémoire.

1. Outils (Donner des mains au modèle)

Un Grand Modèle de Langage (LLM) n'est qu'un cerveau dans un bocal. Il peut penser, mais il ne peut pas toucher le monde. Un "Agent" est simplement un LLM à qui l'on a donné accès à des endpoints d'API ou des commandes CLI.

Vous dites au modèle : "Voici un outil appelé list_files. Voici un outil appelé read_file. Voici un outil appelé send_email."

2. Contexte (Donner une direction au modèle)

Ensuite, vous définissez le rôle. "Tu es un ingénieur QA senior. Ton objectif est de corriger les erreurs de type dans ce dépôt."

C'est tout. C'est la boucle centrale.

Si vous avez utilisé Cursor ou Claude Code, vous avez vu cela en action. Vous ne micro-gérez pas les modifications. Vous dites : "Corrige les erreurs de type dans utils.ts."

L'agent réfléchit : Ok, je dois d'abord voir le fichier. Il décide d'utiliser l'outil ls. Puis il décide d'utiliser grep ou read. Il repère l'erreur. Il décide d'écrire le correctif. Il lance le compilateur pour vérifier son travail.

C'est là que réside la percée. Ce n'est plus juste du "chat". C'est une boucle de décision. Le modèle choisit quels outils saisir pour résoudre le problème que vous lui avez donné.

Des Chatbots aux Moteurs de Décision

Ces deux dernières années, nous sommes restés coincés dans la phase "Chat". Nous traitons l'IA comme un bibliothécaire intelligent — nous posons une question, elle donne une réponse.

Cette phase touche à sa fin.

La phase Agentique concerne l'exécution. Il s'agit de regarder une CLI non pas comme un endroit où vous tapez, mais comme un terrain de jeu pour le modèle.

Pensez aux implications pour les startups. Dans le passé, si je voulais créer un service pour gérer les remboursements clients, je devais construire une interface utilisateur (UI), un backend, une base de données, et embaucher une équipe de support pour cliquer sur les boutons.

Aujourd'hui, je peux écrire un agent. Je lui donne accès à l'API Stripe (Outil) et à notre historique d'emails (Contexte). Je lui donne une politique : "Rembourse si l'utilisateur est mécontent dans les 7 jours." L'agent lit l'email entrant, décide s'il répond aux critères, déclenche l'outil de remboursement Stripe et rédige une réponse.

Pas besoin d'UI. Pas de file d'attente de tickets support. Juste un objectif et un ensemble d'outils.

Le "milieu chaotique" de la création d'agents

Je ne veux pas peindre une utopie ici. J'ai passé les six derniers mois au cœur des tranchées de la création d'agents, et laissez-moi vous dire : c'est le bazar.

Le codage traditionnel est logique. Si X alors Y. Ça marche ou ça casse.

L'ingénierie d'agents est probabiliste. Vous construisez l'agent, vous lui donnez les outils, et parfois il décide d'utiliser un marteau pour ouvrir une fenêtre. Parfois, il hallucine un paramètre qui n'existe pas.

C'est ici que réside le nouvel ensemble de compétences.

Être un Ingénieur d'Agents ne se résume pas à des scripts Python. Il s'agit de :

• Le Prompt Engineering comme Architecture : Concevoir les prompts système pour contraindre le comportement du modèle.
• Eval Driven Development (Développement piloté par l'évaluation) : On ne peut pas écrire de tests unitaires pour la créativité, donc vous construisez des pipelines d'évaluation pour mesurer la fréquence à laquelle l'agent réussit une tâche.
• Conception d'Outils : Créer des interfaces API suffisamment "propres" pour qu'un modèle les comprenne sans s'embrouiller.

J'ai vu des agents rester coincés dans des boucles infinies en essayant de corriger un bug qu'ils avaient eux-mêmes créé. Je les ai vus supprimer le mauvais fichier avec assurance. C'est la réalité. Mais résoudre ces points de friction, c'est exactement là que la valeur est créée.

Conseils pratiques : Comment commencer aujourd'hui

Si je devais repartir de zéro aujourd'hui, ou chercher à faire pivoter ma carrière, voici exactement ce que je ferais :

1. Arrêtez de construire des interfaces graphiques (GUI) : Du moins pour vos side projects. Essayez de résoudre un problème sans frontend. Pouvez-vous le résoudre avec une CLI et un LLM ?
2. Apprenez le protocole d'interface : Comprenez comment fonctionne le "function calling" d'OpenAI ou le "tool use" d'Anthropic. C'est le TCP/IP de l'ère des agents.
3. Construisez un "Faisseur" pas un "Parleur" : Ne construisez pas un bot qui répond à des questions sur votre calendrier. Construisez un bot qui gère votre calendrier. Donnez-lui la capacité de supprimer des événements. Ressentez la peur de donner un accès en écriture à une IA. C'est là que vous commencez vraiment à apprendre.
4. Maîtrisez la gestion du contexte : Apprenez comment insérer les bonnes informations dans la fenêtre de contexte sans la faire déborder. Le RAG (Retrieval-Augmented Generation) n'est que le début.

L'opportunité à venir

Nous regardons vers un avenir où un seul développeur, armé d'une flotte d'agents spécialisés, peut faire le travail d'une startup de 20 personnes.

Les barrières à l'entrée pour la création tombent à zéro. Mais les barrières à l'entrée pour l'orchestration — pour comprendre comment câbler ces cerveaux ensemble — deviennent le nouveau fossé défensif (le fameux "moat").

Il y a dix ans, on vous embauchait pour écrire le code. Aujourd'hui, on vous embauche pour architecturer le système qui écrit le code.

Le train quitte la gare. Vous pouvez soit rester sur le quai en serrant vos vieux frameworks contre vous, soit sauter à bord et aider à construire les rails.

À nous de construire.