Arrêter de coder, bâtir une usine logicielle : l'âge des dispositifs d'agents

Quatre années et des milliers d'heures de pratique, plus de longues conversations avec certaines des personnes les plus affûtées du domaine, se résument en une thèse : l'ère des instructions au coup par coup se termine, et celle des dispositifs d'agents autonomes commence. Dans cette longue conversation diffusée sur YouTube, l'intervenant soutient que son métier, et le vôtre, aura profondément changé dans douze mois, et il le prouve en montant un petit dispositif en direct. Ma lecture : ce n'est pas une démonstration d'outil, c'est une thèse sur le travail assisté qui change de direction.

Chaque grande transformation a déclenché la même peur, et les humains s'y sont adaptés chaque fois. Quand les systèmes automatiques ont remplacé des étages entiers d'employés calculant à la main, la comptabilité n'a pas disparu ; la forme du métier a changé. Face aux agents, la posture doit être la même : raisonner comme un chef d'orchestre, pas comme quelqu'un sur le point d'être remplacé. Ce qui me convainc, c'est la régularité historique : ce ne sont pas les craintifs qui gagnent, mais ceux qui s'adaptent tôt. Vendre la panique est facile ; construire des dispositifs est difficile, et c'est le second qui paie.

Bientôt, chacun de nous dirigera une organisation de milliers d'entités, certaines humaines, la plupart des agents. Dans une telle structure, valider chaque décision une par une est impossible, car même le modèle frontalier le plus vite produit bien plus vite qu'un humain ne peut relire. Maintenir l'humain dans la boucle devient le goulot même qui ralentit le système. Je trouve cette thèse lourde mais juste : débloquer cinq agents à la main est déjà un vrai fardeau aujourd'hui, et en mener cinq cents ainsi est impensable.

Boucles d'agents et usines logicielles

Une boucle d'agents est un dispositif qui prend en charge une petite tâche répétée de bout en bout et tourne seul dès qu'il est déclenché. Quand de nombreuses boucles se rejoignent et fonctionnent sans validation humaine, on obtient une usine logicielle ; une boucle peut encore consulter un humain, une usine doit tourner avec son propre carburant. Mon enseignement pratique : plutôt que rêver d'automatisation grandiose, choisir une petite tâche que je fais chaque jour et la transformer en boucle. Les dispositifs qui commencent étroit grandissent ; ceux qui commencent large se bloquent.

Dans toute organisation, la ressource la plus rare est le temps du dirigeant, et la plupart d'entre nous le dépensent sans savoir où il va. Mesurer le flux du temps pendant quelques semaines révèle l'écart entre la croyance et la réalité : un poste imaginé à vingt pour cent peut se révéler à soixante. L'étape après la mesure consiste à confier une petite part de ce temps à une boucle d'agents. J'aime cette discipline : mesurer d'abord, déléguer une petite part ensuite, et ne pas précipiter l'extension.

Notre manière d'interagir change aussi ; l'ère des questions posées dans une fenêtre de dialogue est derrière nous. Les nouveaux modèles frontaliers sont si vites et si capables que le problème n'est plus de demander, mais de suivre le rythme du flux. Pour quelqu'un qui touche déjà des centaines d'agents par jour, voir ce nombre se multiplier l'an prochain n'aurait rien d'étonnant. L'occasion que j'y vois est là : pendant que la plupart travaille encore avec de vieilles habitudes, ceux qui montent des dispositifs prennent une avance honnête.

Avec l'échelle, les agents isolés cèdent la place à des équipes en couches : un agent chef intelligent répartit le plan, une couche intermédiaire coordonne, des modèles légers et bon marché font le gros du travail. Le rôle d'un agent ne devrait pas être d'accomplir une tâche, mais de lancer et de superviser dix agents ouvriers. Vu ainsi, l'effet de levier change : concevoir des tâches où vingt, cinquante, cent agents font un travail utile devient l'expertise centrale de demain. J'ai adopté ce cadre : on ne conçoit plus des tâches, on conçoit des systèmes qui lancent des tâches.

Même avec un modèle local puissant, tout faire tourner sur un ordinateur personnel se bloque passé un point. Les fenêtres d'autorisation, les onglets qui s'ouvrent et plus de vingt agents qui encombrent l'établi pendant que je travaille ralentissent le rythme et dispersent l'attention. Et quand je veux passer à autre chose, les agents continuent de partager le même environnement. Ma propre pratique le confirme : après quelques travaux parallèles, l'installation locale devient inefficace.

Côté sécurité, la réponse du nuage prend l'avantage ; le point de vue relayé depuis Vercel tient que le nuage offre un terrain bien plus solide pour la sûreté. La logique est simple : quand les agents tournent dans des bacs à sable isolés, une intrusion reste piégée dans un seul environnement et l'établi principal ne risque rien. Le dossier SaasRise confirme le mouvement de Vercel, qui sépare le modèle des agents de déploiement vers une conception en bac à sable. Je trouve cet argument fort : à mesure que la surface d'attaque grandit, l'isolement est une nécessité, pas un luxe.

L'exemple vitrine est un balayage de sécurité approfondi qui tourne toutes les quatre-vingt-dix minutes : le logiciel se sonde sans relâche et repère tôt une porte ouverte. De petites équipes dotées de tels dispositifs peuvent égaler le volume de production d'effectifs de centaines de personnes. La recherche Jellyfish dessine un tableau semblable : les équipes d'ingénierie qui adoptent les outils à fond prennent l'avantage en rendement et en satisfaction. Mon verdict : des tâches ennuyeuses mais critiques comme les balayages de sécurité sont la meilleure publicité de la pensée usine.

Déclencheurs, compétences et économie des modèles

Ce qui lance un dispositif compte autant que son fonctionnement. Le lancement manuel est normal pour une période de transition, mais le but est d'écarter la personne : tourner à horaire fixe, se réveiller sur événement extérieur, se déclencher sur un mouvement dans le dépôt logiciel. Des stimuli extérieurs comme les crochets web et les signaux d'erreur sont les pièces qui rendent un dispositif vraiment autonome. Ma suggestion : noter chaque tâche lancée à la main et revoir régulièrement lesquelles pourraient être planifiées.

L'idée des Agent Skills portée par Anthropic rend l'expertise emballable : un dossier de guides, de scripts et de fichiers de référence transforme un agent généraliste en recrue formée, prête pour une mission spéciale. La connexion au monde extérieur passe par une porte protocolaire universelle ; la compétence porte la procédure intérieure tandis que le protocole nommé MCP porte l'accès extérieur. L'examen Ravichaganti distingue nettement ce duo : l'un dépense le budget de contexte avec efficacité et ne remplace pas l'autre. Je tiens à cette distinction : tout écraser dans un seul standard devient cher et fragile.

Je m'attends à voir venir les chaînes de compétences : les systèmes déduiront des traces d'agents passées d'une personne quelles étapes se suivent et proposeront la séquence probable. Si trois opérations s'enchaînent avec une forte probabilité dans une situation donnée, le système les offrira en un seul paquet. C'est une couche qui apprend du comportement observé. J'éprouve une curiosité prudente : le rendement monte, mais les questions de traçage et de confidentialité grandissent avec lui.

L'économie des abonnements dessine aussi le tableau : les paliers d'entrée, de milieu et de sommet sont proposés à prix semblables des deux côtés, pourtant le choix du modèle multiplie le travail sorti du même forfait. La comparaison Replicas met côte à côte les coûts en tokens et les fenêtres de contexte des modèles frontaliers et rend le tableau concret. L'examen Coursiv pointe dans le même sens : les limites se révèlent plus à l'usage réel que dans les annonces. Ma conclusion : à l'achat d'un forfait, regarder le travail par budget, pas le prix.

Côté comparaisons, les scores restent proches : le résumé Daily.dev place les taux de justesse des deux outils côte à côte à moins d'un point. Les mesures Terminal-Bench du côté Replicas montrent une proximité semblable, l'écart s'ouvrant dans la manière de travailler. Le gagnant n'est donc pas un modèle mais un ajustement de flux de travail. Je trouve ce résultat important : c'est une décision de manière de travailler, pas une liste de courses.

En pratique, les deux styles se complètent : l'assistant tournant en local mène dans le travail interactif supervisé, la flotte du nuage dans les lots confiés puis relus plus tard. La comparaison Daily.dev trace cette frontière nettement : l'un pour les corrections en direct, l'autre pour les lots délégués. Coursiv confirme le motif du double usage : la plupart des équipes font tourner l'un comme superviseur et l'autre comme flotte d'arrière-plan. Mon conseil rejoint ce constat : répartir par type de tâche au lieu d'épouser un seul outil.

La recherche offre un optimisme prudent : la note METR rapporte que le constat précoce de ralentissement s'inverse avec les nouvelles versions, les participants refusant d'abandonner les outils. Cela complique la mesure mais indique la direction. Ma lecture : le gain de rendement est désormais une observation, pas une promesse, mais il ne se répartit pas également. Ce qui creuse l'écart, ce n'est pas l'outil lui-même, mais la discipline de monter des dispositifs.

Mot de la fin : les ciseaux s'ouvrent, et l'écart de production entre les monteurs de dispositifs et ceux qui restent aux forfaits d'entrée grandit chaque mois. Le coût est moindre qu'on ne croit ; le vrai coût, c'est d'attendre. La démonstration en direct dans la conversation le prouve : un dispositif simple, né d'une courte consigne vocale, devient une ligne qui relit le produit sans arrêt. Mon appel est clair : commencer aujourd'hui avec une petite boucle, faire grandir l'usine avec le temps.