Nouveaux modèles de développement à l’ère de l’IA

xguru · 2025-05-26T11:03:01+09:00

Une culture de développement émerge qui traite l’IA non plus comme un simple outil, mais comme une technologie de base Les approches traditionnelles de gestion de versions, de dashboards, de templates, de documentation et de gestion des secrets évoluent pour s’adapter à l’ère de l’IA Git n’est plus seulement interprété comme un suivi des modifications ligne par ligne du code, mais comme un mode de gestion d’état centré sur les prompts et les résultats de test Les agents deviennent à la fois auteurs et consommateurs de code, ce qui renforce le besoin de repenser les outils eux-mêmes Les dashboards et les UI évoluent vers des interfaces en langage naturel, conçues pour être utilisées conjointement par des humains et des agents IA La documentation se transforme en base de connaissances pour les humains comme pour l’IA, restructurée dans un format compréhensible par les agents 1. AI-Native Git : redéfinir la gestion de versions pour les agents IA Git a été conçu à l’origine pour suivre l’historique des changements ligne par ligne dans du code écrit directement par des humains Mais dans un contexte où l’IA génère et modifie automatiquement de larges portions de code, ce suivi fin devient moins important Les développeurs se concentrent alors moins sur les changements eux-mêmes que sur la pertinence du comportement obtenu (tests réussis, fonctionnement correct, etc.) Un SHA indique qu’un changement a eu lieu, mais ne contient pas d’information sur la raison de ce changement ni sur sa validité En particulier dans le cas de modifications de grande ampleur ou de code généré automatiquement, les développeurs ne passent pas systématiquement chaque diff en revue Dans un workflow AI-first, la combinaison des éléments suivants devient une unité plus utile Prompt : l’entrée qui a guidé la génération du code Test : les tests servant à vérifier le comportement attendu Spécification (spec) et contraintes (constraints) : les exigences de conception L’ensemble est alors géré et suivi comme un bundle versionnable En poussant cette logique plus loin, dans un workflow piloté par des agents, la source de vérité peut remonter en amont vers les prompts, les schémas de données, les contrats d’API et l’intention architecturale (intent) Au final, le code est traité comme un artefact compilé, et non comme la source elle-même, mais comme le sous-produit de ces entrées Git fonctionne alors non plus comme un workspace de code, mais comme un journal d’artefacts (artifact log) qui a produit le code, avec quel modèle et quel prompt quels tests ont été validés quelles parties doivent être revues par un humain, ainsi que d’autres métadonnées L’historique des changements inclut les prompts, l’objectif, les tests associés et les informations sur le modèle ayant généré le code Une intégration avec des outils de revue IA comme Diamond permettrait des workflows de revue automatisés On peut aussi imaginer une structuration en couches de métadonnées plus riches, capable de distinguer le code généré par des agents des zones protégées gérées par des humains Si l’on projette un workflow AI-Native Git on peut imaginer une nouvelle forme de dashboard Git affichant ensemble les prompts, le flux des modifications qui en découlent, les résultats de test, les informations sur les agents exécutés et les bundles associés 2. Dashboards → Synthesis : évolution vers des interfaces dynamiques basées sur l’IA Pendant des années, les dashboards ont servi d’interface principale pour interagir avec des systèmes complexes comme les plateformes d’observabilité, les outils d’analytics ou les consoles cloud (AWS, etc.) Mais la multiplication des éléments de contrôle, des graphiques et des onglets a provoqué une surcharge UX, dans laquelle l’utilisateur se perd facilement entre exploration de l’information et passage à l’action En particulier pour les non-spécialistes ou dans des contextes de collaboration entre plusieurs équipes, ces dashboards peuvent être perçus comme des outils intimidants et inefficaces Les utilisateurs savent souvent ce qu’ils veulent accomplir, mais pas où chercher ni quels filtres appliquer La dernière génération de modèles d’IA laisse entrevoir une solution possible à ce problème Il devient possible de réinterpréter le dashboard non plus comme une surface figée, mais comme un espace d’exploration et d’interaction Les LLM peuvent aider les utilisateurs de plusieurs façons : repérer l’emplacement d’un contrôle, par exemple : « Où puis-je modifier le paramètre de limitation de débit de cette API ? » fournir une synthèse consolidée de données, par exemple : « Résume-moi la tendance des erreurs sur tous les services de l’environnement de staging au cours des dernières 24 heures » proposer des insights cachés, par exemple : « Recommande-moi les métriques à surveiller ce trimestre en fonction de mon contexte business » Des technologies comme Assistant UI permettent déjà à des agents d’utiliser des composants React comme des outils De la même façon que le contenu devient dynamique et personnalisé, l’UI elle-même se recompose selon l’intention de l’utilisateur et évolue vers davantage d’interactivité Les dashboards statiques pourraient bientôt être perçus comme dépassés Exemples : si un utilisateur dit « Montre-moi les anomalies survenues en Europe le week-end dernier », des logs synthétisés et des tendances peuvent être fournis automatiquement sans manipulation manuelle des filtres à la question « Pourquoi le score NPS a-t-il baissé la semaine dernière ? », l’IA peut fournir une analyse de sentiment des enquêtes, une corrélation avec les déploiements produit et un résumé de diagnostic Dans une perspective plus large, si les agents deviennent des consommateurs de logiciels, la notion même de “dashboard” doit être repensée Par exemple, un dashboard pourrait rendre une vue optimisée pour Agent Experience en offrant une interface structurée et accessible de manière programmatique permettant de comprendre l’état du système, de prendre des décisions et d’agir Il pourrait en résulter une architecture d’interface double, avec une UI pour les humains et une UI pour les agents les deux partageraient le même état, mais seraient organisées différemment selon le mode de consommation Les agents remplaceraient les alertes traditionnelles, les cron jobs et les automatisations conditionnelles, tout en devenant des opérateurs bien plus riches en contexte et en flexibilité Exemple : traditionnel : if error rate > threshold then send alert version pilotée par agent : « Le taux d’erreur est en hausse. La cause est ce service, et voici les composants affectés ainsi que les actions recommandées » Ainsi, le dashboard n’est plus seulement un lieu d’observation, mais un espace où humains et IA collaborent, synthétisent et passent à l’action 3. La documentation évolue vers une combinaison d’outil, d’index et de base de connaissances interactive La manière dont les développeurs utilisent la documentation est en train de changer Autrefois, on lisait une spécification de haut en bas ou en suivant la table des matières, mais désormais la démarche “poser d’abord une question” devient la norme Au lieu de penser « je vais étudier cette spécification », on voit apparaître un changement de perspective : « restructure l’information dans la forme que je veux » Cette évolution influe aussi sur la forme même de la documentation, qui n’évolue plus vers du HTML ou du Markdown statique, mais vers un système de connaissances interactif soutenu par des index, des embeddings et des agents capables de reconnaître des outils C’est dans ce contexte qu’apparaissent des outils comme Mintlify Mintlify ne se contente pas d’organiser la documentation comme une base de données interrogeable sémantiquement, il en fait aussi une source de contexte pour des agents sur différentes plateformes Exemple : dans des IDE IA, des extensions VS Code ou des agents en terminal, la documentation Mintlify est utilisée comme référence en temps réel La raison est que les agents de génération de code utilisent la documentation la plus récente comme contexte d’apprentissage Cela change la finalité même de la documentation Elle n’a plus seulement pour fonction de transmettre de l’information à des lecteurs humains, mais doit désormais être conçue comme une structure destinée à des agents consommateurs Dans cette nouvelle dynamique, la documentation joue le rôle de guide d’utilisation pour les agents IA Il ne s’agit plus simplement d’exposer du contenu, mais de décrire comment utiliser correctement un système 4. Des templates à la génération : le vibe coding qui remplace create-react-app Autrefois, pour démarrer un projet, il était courant de choisir un template statique comme create-react-app, next init ou rails new Ces templates fournissaient une structure d’app cohérente, mais il était difficile de les personnaliser en fonction de l’intention du développeur ou de sa stack, et il fallait suivre les valeurs par défaut du framework En conséquence, s’écarter de la configuration de base nécessitait beaucoup de refactoring manuel Aujourd’hui, cette logique évolue avec l’émergence de plateformes text-to-app comme Replit, Same.dev, Loveable, Chef by Convex, Bolt, ainsi que d’IDE IA comme Cursor Par exemple, si un développeur décrit « un serveur d’API TypeScript avec Supabase, Clerk et Stripe », l’IA configure automatiquement un projet sur mesure en quelques secondes Le starter généré n’est plus un template générique, mais une structure optimisée pour l’intention et la stack du développeur Cette évolution transforme aussi la structure de diffusion de l’écosystème Au lieu d’avoir quelques frameworks au centre de l’écosystème comme auparavant, on voit se répandre des flux de génération sur mesure combinant divers outils et architectures L’essentiel n’est plus de choisir un framework, mais d’expliquer ce que l’on veut construire Qu’un développeur choisisse la combinaison Next.js + tRPC, et un autre Vite + React, il devient possible de générer dans les deux cas un projet immédiatement exécutable Bien sûr, les stacks standard conservent aussi des avantages : amélioration de la productivité des équipes, efficacité de l’onboarding, facilité du débogage, etc. Mais le refactoring entre frameworks n’est pas seulement un problème technique : il est lié au produit, à l’infrastructure et aux capacités de l’organisation Le point de bascule, c’est justement la baisse du coût de changement de framework Les agents IA comprennent l’intention du projet et peuvent effectuer semi-automatiquement des refactorings à grande échelle Cela facilite l’expérimentation et crée une marge pour essayer différentes stacks au début d’un projet, ou revenir en arrière En conséquence, le choix du framework devient réversible (decision reversible) Exemple : commencer avec Next.js, puis passer à Remix + Vite, pendant que l’agent prend en charge l’ensemble du refactoring Le lock-in framework diminue, ce qui permet d’essayer sans contrainte des stacks opinionated 5. Au-delà du .env : la gestion des secrets dans un environnement centré sur les agents Pendant des décennies, les fichiers .env ont constitué pour les développeurs le moyen de base pour gérer simplement en local des secrets comme des clés API, des URL de base de données ou des tokens de service Cette méthode est simple, portable et adaptée aux développeurs, mais elle pose problème dans un contexte où des IDE IA ou des agents écrivent du code, déploient des services et orchestrent des environnements En d’autres termes, on ne sait plus clairement qui est le propriétaire du fichier .env Une nouvelle tendance apparaît pour résoudre ce problème Par exemple, la dernière spécification MCP inclut un framework d’authentification basé sur OAuth 2.1 Cette architecture suggère une direction où l’on donne aux agents IA des tokens à portée limitée (scope-based, revocable tokens) au lieu de secrets bruts Exemple : au lieu de fournir à un agent une clé AWS complète, on lui donne des identifiants temporaires n’autorisant qu’une action limitée, comme « téléverser un fichier sur S3 » Une autre tendance est l’apparition de brokers de secrets locaux (secret brokers) Ils s’exécutent en local ou à côté de l’application et jouent le rôle de service intermédiaire entre l’agent et les secrets sensibles L’agent n’accède pas directement au .env et ne hardcode rien ; lorsqu’une tâche précise est demandée, le broker l’évalue en temps réel et accorde les autorisations nécessaires Exemple : demande de « déployer en staging » ou « envoyer les logs à Sentry » Le broker traite cela en just-in-time, et tous les accès peuvent être tracés dans un audit Cette approche fait évoluer l’accès aux secrets d’un modèle fondé sur le système de fichiers vers un modèle d’autorisations basé sur des API En conséquence, la gestion des secrets évolue d’une configuration .env vers une structure de contrôle des autorisations fondée sur OAuth 6. Faire de l’accessibilité une interface universelle : la vision des apps du point de vue des LLM Récemment, des apps comme Granola et Highlight demandent l’accès aux réglages d’accessibilité de macOS, non pas dans le but traditionnel d’aider les personnes en situation de handicap, mais pour permettre à des agents IA d’observer l’interface et d’interagir avec elle Ce n’est pas un hack temporaire, mais plutôt le signe avant-coureur d’un changement d’interface plus fondamental Les API d’accessibilité ont été conçues à l’origine pour améliorer l’accessibilité numérique des personnes ayant des handicaps visuels ou moteurs Mais en les étendant, elles peuvent servir de couche d’interface universelle pour les agents IA Au lieu de cliquer sur des positions de pixels ou de faire du scraping du DOM, les agents peuvent observer et faire fonctionner une app de manière sémantique, comme le font les technologies d’assistance pour interpréter une UI Les arbres d’accessibilité exposent déjà des éléments d’UI structurés comme des boutons, des titres ou des champs de saisie Si on y ajoute des métadonnées comme l’intention (intent), le rôle (role) et les possibilités d’action (affordance), les agents peuvent manipuler l’interface avec précision en fonction de l’objectif et du contexte Cette orientation pourrait s’étendre à des fonctions comme : Context extraction : interroger, via des API d’accessibilité/sémantiques, les éléments visibles à l’écran, les éléments interactifs et l’action en cours de l’utilisateur Intentful execution : au lieu de relier manuellement plusieurs appels d’API, déclarer un objectif de haut niveau comme « ajouter un article au panier et choisir la livraison la plus rapide », puis laisser le backend composer la procédure d’exécution Fallback UI for LLMs : les fonctions d’accessibilité fournissent une interface de secours permettant aux agents d’utiliser aussi des apps qui n’ont pas d’API publique Les développeurs peuvent définir, au-delà de l’UI visuelle ou du DOM, une render surface lisible par les agents à l’aide d’annotations structurées ou de composants centrés sur l’accessibilité En résumé, les API d’accessibilité évoluent : elles ne sont plus uniquement destinées aux humains, mais deviennent une couche d’interface clé pour les interactions entre l’IA et les systèmes 7. L’essor du travail asynchrone des agents À mesure que les développeurs collaborent plus naturellement avec des agents de génération de code, la transition vers des workflows asynchrones s’accélère Les agents travaillent en parallèle en arrière-plan et rendent compte des résultats une fois un certain niveau d’avancement atteint Cette interaction se rapproche de plus en plus d’une orchestration de tâches (task orchestration) plutôt que du pair programming Autrement dit, le développeur transmet un objectif, l’agent l’exécute, puis le résultat est vérifié plus tard Le point important n’est pas seulement d’alléger le travail, mais de compresser la collaboration elle-même Par exemple, au lieu de demander à une autre équipe une mise à jour de fichier de configuration, un triage d’erreurs ou un refactoring de composant, le développeur peut communiquer directement son intention à l’agent et lui demander de traiter cela en arrière-plan Là où il fallait auparavant des réunions synchrones, des handoffs entre équipes et de longs cycles de revue, une boucle requête → génération → validation (request → generate → validate) s’installe désormais naturellement La façon d’interagir avec les agents s’élargit également Au-delà de la simple saisie de prompts dans un IDE ou un CLI, il devient possible de : demander une tâche via un message Slack laisser un commentaire sur une maquette Figma ajouter des commentaires inline sur un diff de code ou une PR (ex. : l’assistant de revue Graphite) ajouter du feedback sur la preview d’une application déployée décrire oralement des changements via une interface vocale ou basée sur un appel Ces évolutions font des agents une présence sur l’ensemble du cycle de vie du développement Ils ne se limitent plus à écrire du code : ils interprètent aussi le design, intègrent les retours et vont jusqu’au triage de bugs à l’échelle de la plateforme Le développeur endosse un rôle d’orchestrateur (orchestrator), en décidant quels fils de travail faire avancer, écarter ou fusionner Cette dynamique suggère à terme que les fils de travail pilotés par des agents pourraient devenir le nouveau concept de « branche Git » Il ne s’agirait plus d’un fork de code statique, mais de fils dynamiques orientés objectif, exécutés de manière asynchrone puis intégrés une fois terminés 8. MCP : un pas de plus vers un standard universel pour le Model Context Protocol Depuis la publication récente de cette analyse approfondie sur MCP, l’adoption de MCP s’accélère OpenAI a officiellement adopté MCP, plusieurs nouvelles fonctionnalités ont été intégrées à la spécification, et un nombre croissant de créateurs d’outils adoptent MCP comme interface par défaut entre les agents et le monde réel MCP résout fondamentalement deux problèmes importants : fournir le contexte nécessaire pour qu’un LLM puisse exécuter même une tâche qu’il rencontre pour la première fois éliminer les intégrations sur mesure de type N×M et simplifier le tout en une structure où les outils exposent une interface standardisée (serveur), utilisable par tous les agents (clients) L’adoption de MCP devrait encore s’élargir à l’avenir, et avec l’émergence de MCP distant et d’un registre MCP de facto (de-facto registry), de nombreuses applications pourraient être lancées avec une interface MCP intégrée par défaut De la même manière que les API ont permis de connecter les outils SaaS et de composer des workflows, MCP pourrait faire émerger un écosystème de composants interopérables pour les agents IA Une plateforme qui intègre un client MCP n’est plus simplement « compatible IA », mais devient une partie d’un écosystème directement connectable à un réseau de fonctionnalités accessibles aux agents Les clients et serveurs MCP ne sont que des concepts logiques, sans séparation physique stricte Cela signifie que n’importe quel client MCP peut devenir serveur, et inversement Cela ouvre la voie à une composabilité très avancée : ex. : un agent de code peut récupérer des issues GitHub en tant que client et, en même temps, fournir à d’autres agents une couverture de tests ou des résultats d’analyse de code en tant que serveur MCP est en train de s’imposer comme la couche d’interface fondamentale d’un écosystème où outils et agents interagissent de manière organique 9. Primitives abstraites : authentification, paiement et stockage dont tous les agents IA ont besoin À mesure que les agents de vibe coding gagnent en puissance, une évidence s’impose : ils peuvent générer beaucoup de code, mais ce code a besoin d’une base fiable à laquelle se connecter De la même manière qu’un développeur humain s’appuie sur Stripe pour les paiements, Clerk pour l’authentification et Supabase pour la base de données, les agents ont eux aussi besoin de primitives de service fiables et combinables Ces services offrent des frontières d’API claires, des SDK faciles à utiliser et des paramètres par défaut raisonnables, et jouent de plus en plus le rôle d’interface d’exécution pour les agents Par exemple, lors de la création d’un outil qui génère une application SaaS, au lieu que l’agent implémente lui-même un système d’authentification ou une logique de paiement, il peut intégrer Clerk et Stripe rapidement et de façon sûre À mesure que ce modèle gagne en maturité, les services pourront aller au-delà de la simple exposition d’API et publier aussi : des schémas (schema) : définitions de données structurées des métadonnées de capacités (capability metadata) : spécifications des actions réalisables des example flows : exemples de méthodes d’intégration → permettant ainsi aux agents d’intégrer ces services de manière plus fiable Certains services pourraient même être lancés avec un serveur MCP intégré ex. : Clerk pourrait exposer via un serveur MCP des fonctions comme la consultation de la liste des produits disponibles, la création d’un nouveau plan tarifaire ou la modification d’un abonnement Au lieu de chercher une spécification d’API ou de lire la documentation, l’agent formule une demande en langage naturel, et le serveur MCP valide et traite la requête dans les limites des permissions et des contraintes définies ex. : > « Crée un plan Pro à 49 $/mois et ajoute une facturation complémentaire basée sur l’usage » → le serveur MCP de Clerk interprète cette demande et l’exécute De la même façon que rails new a permis un développement rapide aux débuts du web, l’ère des agents a besoin de primitives fiables (drop-in identity, paiement, contrôle d’accès, etc.) elles doivent être suffisamment abstraites pour que les agents puissent les exploiter pour la génération, tout en reposant sur une architecture capable de passer à l’échelle avec la croissance de l’application Conclusion Ces 9 modèles montrent qu’il ne s’agit pas simplement d’ajouter l’IA aux méthodes de développement existantes, mais bien d’une redéfinition de la façon de produire des logiciels autour des agents, du contexte et de l’intention En conséquence, les comportements traditionnels des développeurs évoluent eux aussi, et de nouvelles toolchains et de nouveaux protocoles (dont MCP) émergent rapidement pour les soutenir Les couches d’outils fondamentales existantes, comme Git, les templates, les dashboards ou les méthodes de documentation, sont en train d’être repensées en profondeur avec l’IA Dans cette phase de transition, on peut s’attendre à une forte activité de construction et d’investissement autour des outils et infrastructures de nouvelle génération qui composeront le nouvel écosystème du développement

(a16z.com)

48 points par xguru 2025-05-26 | 8 commentaires | Partager sur WhatsApp

Une culture de développement émerge qui traite l’IA non plus comme un simple outil, mais comme une technologie de base
Les approches traditionnelles de gestion de versions, de dashboards, de templates, de documentation et de gestion des secrets évoluent pour s’adapter à l’ère de l’IA
- Git n’est plus seulement interprété comme un suivi des modifications ligne par ligne du code, mais comme un mode de gestion d’état centré sur les prompts et les résultats de test
- Les agents deviennent à la fois auteurs et consommateurs de code, ce qui renforce le besoin de repenser les outils eux-mêmes
- Les dashboards et les UI évoluent vers des interfaces en langage naturel, conçues pour être utilisées conjointement par des humains et des agents IA
- La documentation se transforme en base de connaissances pour les humains comme pour l’IA, restructurée dans un format compréhensible par les agents

1. AI-Native Git : redéfinir la gestion de versions pour les agents IA

Git a été conçu à l’origine pour suivre l’historique des changements ligne par ligne dans du code écrit directement par des humains
- Mais dans un contexte où l’IA génère et modifie automatiquement de larges portions de code, ce suivi fin devient moins important
- Les développeurs se concentrent alors moins sur les changements eux-mêmes que sur la pertinence du comportement obtenu (tests réussis, fonctionnement correct, etc.)
- Un SHA indique qu’un changement a eu lieu, mais ne contient pas d’information sur la raison de ce changement ni sur sa validité
- En particulier dans le cas de modifications de grande ampleur ou de code généré automatiquement, les développeurs ne passent pas systématiquement chaque diff en revue
Dans un workflow AI-first, la combinaison des éléments suivants devient une unité plus utile
- Prompt : l’entrée qui a guidé la génération du code
- Test : les tests servant à vérifier le comportement attendu
- Spécification (spec) et contraintes (constraints) : les exigences de conception
- L’ensemble est alors géré et suivi comme un bundle versionnable
En poussant cette logique plus loin, dans un workflow piloté par des agents, la source de vérité peut remonter en amont vers les prompts, les schémas de données, les contrats d’API et l’intention architecturale (intent)
- Au final, le code est traité comme un artefact compilé, et non comme la source elle-même, mais comme le sous-produit de ces entrées
- Git fonctionne alors non plus comme un workspace de code, mais comme un journal d’artefacts (artifact log)
  - qui a produit le code, avec quel modèle et quel prompt
  - quels tests ont été validés
  - quelles parties doivent être revues par un humain, ainsi que d’autres métadonnées
L’historique des changements inclut les prompts, l’objectif, les tests associés et les informations sur le modèle ayant généré le code
- Une intégration avec des outils de revue IA comme Diamond permettrait des workflows de revue automatisés
- On peut aussi imaginer une structuration en couches de métadonnées plus riches, capable de distinguer le code généré par des agents des zones protégées gérées par des humains
Si l’on projette un workflow AI-Native Git
- on peut imaginer une nouvelle forme de dashboard Git affichant ensemble les prompts, le flux des modifications qui en découlent, les résultats de test, les informations sur les agents exécutés et les bundles associés

2. Dashboards → Synthesis : évolution vers des interfaces dynamiques basées sur l’IA

Pendant des années, les dashboards ont servi d’interface principale pour interagir avec des systèmes complexes comme les plateformes d’observabilité, les outils d’analytics ou les consoles cloud (AWS, etc.)
- Mais la multiplication des éléments de contrôle, des graphiques et des onglets a provoqué une surcharge UX, dans laquelle l’utilisateur se perd facilement entre exploration de l’information et passage à l’action
- En particulier pour les non-spécialistes ou dans des contextes de collaboration entre plusieurs équipes, ces dashboards peuvent être perçus comme des outils intimidants et inefficaces
- Les utilisateurs savent souvent ce qu’ils veulent accomplir, mais pas où chercher ni quels filtres appliquer
La dernière génération de modèles d’IA laisse entrevoir une solution possible à ce problème
- Il devient possible de réinterpréter le dashboard non plus comme une surface figée, mais comme un espace d’exploration et d’interaction
Les LLM peuvent aider les utilisateurs de plusieurs façons :
- repérer l’emplacement d’un contrôle, par exemple : « Où puis-je modifier le paramètre de limitation de débit de cette API ? »
- fournir une synthèse consolidée de données, par exemple : « Résume-moi la tendance des erreurs sur tous les services de l’environnement de staging au cours des dernières 24 heures »
- proposer des insights cachés, par exemple : « Recommande-moi les métriques à surveiller ce trimestre en fonction de mon contexte business »
Des technologies comme Assistant UI permettent déjà à des agents d’utiliser des composants React comme des outils
- De la même façon que le contenu devient dynamique et personnalisé, l’UI elle-même se recompose selon l’intention de l’utilisateur et évolue vers davantage d’interactivité
- Les dashboards statiques pourraient bientôt être perçus comme dépassés
- Exemples :
  - si un utilisateur dit « Montre-moi les anomalies survenues en Europe le week-end dernier », des logs synthétisés et des tendances peuvent être fournis automatiquement sans manipulation manuelle des filtres
  - à la question « Pourquoi le score NPS a-t-il baissé la semaine dernière ? », l’IA peut fournir une analyse de sentiment des enquêtes, une corrélation avec les déploiements produit et un résumé de diagnostic
Dans une perspective plus large, si les agents deviennent des consommateurs de logiciels, la notion même de “dashboard” doit être repensée
- Par exemple, un dashboard pourrait rendre une vue optimisée pour Agent Experience
  - en offrant une interface structurée et accessible de manière programmatique permettant de comprendre l’état du système, de prendre des décisions et d’agir
- Il pourrait en résulter une architecture d’interface double, avec une UI pour les humains et une UI pour les agents
  - les deux partageraient le même état, mais seraient organisées différemment selon le mode de consommation
Les agents remplaceraient les alertes traditionnelles, les cron jobs et les automatisations conditionnelles, tout en devenant des opérateurs bien plus riches en contexte et en flexibilité
Exemple :
- traditionnel : if error rate > threshold then send alert
- version pilotée par agent : « Le taux d’erreur est en hausse. La cause est ce service, et voici les composants affectés ainsi que les actions recommandées »
Ainsi, le dashboard n’est plus seulement un lieu d’observation, mais un espace où humains et IA collaborent, synthétisent et passent à l’action

3. La documentation évolue vers une combinaison d’outil, d’index et de base de connaissances interactive

La manière dont les développeurs utilisent la documentation est en train de changer
- Autrefois, on lisait une spécification de haut en bas ou en suivant la table des matières, mais désormais la démarche “poser d’abord une question” devient la norme
- Au lieu de penser « je vais étudier cette spécification », on voit apparaître un changement de perspective : « restructure l’information dans la forme que je veux »
- Cette évolution influe aussi sur la forme même de la documentation, qui n’évolue plus vers du HTML ou du Markdown statique, mais vers un système de connaissances interactif soutenu par des index, des embeddings et des agents capables de reconnaître des outils
C’est dans ce contexte qu’apparaissent des outils comme Mintlify
- Mintlify ne se contente pas d’organiser la documentation comme une base de données interrogeable sémantiquement, il en fait aussi une source de contexte pour des agents sur différentes plateformes
  - Exemple : dans des IDE IA, des extensions VS Code ou des agents en terminal, la documentation Mintlify est utilisée comme référence en temps réel
- La raison est que les agents de génération de code utilisent la documentation la plus récente comme contexte d’apprentissage
Cela change la finalité même de la documentation
- Elle n’a plus seulement pour fonction de transmettre de l’information à des lecteurs humains, mais doit désormais être conçue comme une structure destinée à des agents consommateurs
- Dans cette nouvelle dynamique, la documentation joue le rôle de guide d’utilisation pour les agents IA
- Il ne s’agit plus simplement d’exposer du contenu, mais de décrire comment utiliser correctement un système

4. Des templates à la génération : le vibe coding qui remplace create-react-app

Autrefois, pour démarrer un projet, il était courant de choisir un template statique comme create-react-app, next init ou rails new
- Ces templates fournissaient une structure d’app cohérente, mais il était difficile de les personnaliser en fonction de l’intention du développeur ou de sa stack, et il fallait suivre les valeurs par défaut du framework
- En conséquence, s’écarter de la configuration de base nécessitait beaucoup de refactoring manuel
Aujourd’hui, cette logique évolue avec l’émergence de plateformes text-to-app comme Replit, Same.dev, Loveable, Chef by Convex, Bolt, ainsi que d’IDE IA comme Cursor
- Par exemple, si un développeur décrit « un serveur d’API TypeScript avec Supabase, Clerk et Stripe », l’IA configure automatiquement un projet sur mesure en quelques secondes
- Le starter généré n’est plus un template générique, mais une structure optimisée pour l’intention et la stack du développeur
Cette évolution transforme aussi la structure de diffusion de l’écosystème
- Au lieu d’avoir quelques frameworks au centre de l’écosystème comme auparavant, on voit se répandre des flux de génération sur mesure combinant divers outils et architectures
- L’essentiel n’est plus de choisir un framework, mais d’expliquer ce que l’on veut construire
- Qu’un développeur choisisse la combinaison Next.js + tRPC, et un autre Vite + React, il devient possible de générer dans les deux cas un projet immédiatement exécutable
Bien sûr, les stacks standard conservent aussi des avantages :
- amélioration de la productivité des équipes, efficacité de l’onboarding, facilité du débogage, etc.
- Mais le refactoring entre frameworks n’est pas seulement un problème technique : il est lié au produit, à l’infrastructure et aux capacités de l’organisation
Le point de bascule, c’est justement la baisse du coût de changement de framework
- Les agents IA comprennent l’intention du projet et peuvent effectuer semi-automatiquement des refactorings à grande échelle
- Cela facilite l’expérimentation et crée une marge pour essayer différentes stacks au début d’un projet, ou revenir en arrière
En conséquence, le choix du framework devient réversible (decision reversible)
- Exemple : commencer avec Next.js, puis passer à Remix + Vite, pendant que l’agent prend en charge l’ensemble du refactoring
Le lock-in framework diminue, ce qui permet d’essayer sans contrainte des stacks opinionated

5. Au-delà du `.env` : la gestion des secrets dans un environnement centré sur les agents

Pendant des décennies, les fichiers .env ont constitué pour les développeurs le moyen de base pour gérer simplement en local des secrets comme des clés API, des URL de base de données ou des tokens de service
- Cette méthode est simple, portable et adaptée aux développeurs, mais elle pose problème dans un contexte où des IDE IA ou des agents écrivent du code, déploient des services et orchestrent des environnements
- En d’autres termes, on ne sait plus clairement qui est le propriétaire du fichier .env
Une nouvelle tendance apparaît pour résoudre ce problème
- Par exemple, la dernière spécification MCP inclut un framework d’authentification basé sur OAuth 2.1
- Cette architecture suggère une direction où l’on donne aux agents IA des tokens à portée limitée (scope-based, revocable tokens) au lieu de secrets bruts
- Exemple : au lieu de fournir à un agent une clé AWS complète, on lui donne des identifiants temporaires n’autorisant qu’une action limitée, comme « téléverser un fichier sur S3 »
Une autre tendance est l’apparition de brokers de secrets locaux (secret brokers)
- Ils s’exécutent en local ou à côté de l’application et jouent le rôle de service intermédiaire entre l’agent et les secrets sensibles
- L’agent n’accède pas directement au .env et ne hardcode rien ; lorsqu’une tâche précise est demandée, le broker l’évalue en temps réel et accorde les autorisations nécessaires
  - Exemple : demande de « déployer en staging » ou « envoyer les logs à Sentry »
  - Le broker traite cela en just-in-time, et tous les accès peuvent être tracés dans un audit
Cette approche fait évoluer l’accès aux secrets d’un modèle fondé sur le système de fichiers vers un modèle d’autorisations basé sur des API
- En conséquence, la gestion des secrets évolue d’une configuration .env vers une structure de contrôle des autorisations fondée sur OAuth

6. Faire de l’accessibilité une interface universelle : la vision des apps du point de vue des LLM

Récemment, des apps comme Granola et Highlight demandent l’accès aux réglages d’accessibilité de macOS, non pas dans le but traditionnel d’aider les personnes en situation de handicap, mais pour permettre à des agents IA d’observer l’interface et d’interagir avec elle
- Ce n’est pas un hack temporaire, mais plutôt le signe avant-coureur d’un changement d’interface plus fondamental
Les API d’accessibilité ont été conçues à l’origine pour améliorer l’accessibilité numérique des personnes ayant des handicaps visuels ou moteurs
- Mais en les étendant, elles peuvent servir de couche d’interface universelle pour les agents IA
- Au lieu de cliquer sur des positions de pixels ou de faire du scraping du DOM, les agents peuvent observer et faire fonctionner une app de manière sémantique, comme le font les technologies d’assistance pour interpréter une UI
- Les arbres d’accessibilité exposent déjà des éléments d’UI structurés comme des boutons, des titres ou des champs de saisie
- Si on y ajoute des métadonnées comme l’intention (intent), le rôle (role) et les possibilités d’action (affordance), les agents peuvent manipuler l’interface avec précision en fonction de l’objectif et du contexte
Cette orientation pourrait s’étendre à des fonctions comme :
- Context extraction : interroger, via des API d’accessibilité/sémantiques, les éléments visibles à l’écran, les éléments interactifs et l’action en cours de l’utilisateur
- Intentful execution : au lieu de relier manuellement plusieurs appels d’API, déclarer un objectif de haut niveau comme « ajouter un article au panier et choisir la livraison la plus rapide », puis laisser le backend composer la procédure d’exécution
- Fallback UI for LLMs : les fonctions d’accessibilité fournissent une interface de secours permettant aux agents d’utiliser aussi des apps qui n’ont pas d’API publique
  - Les développeurs peuvent définir, au-delà de l’UI visuelle ou du DOM, une render surface lisible par les agents à l’aide d’annotations structurées ou de composants centrés sur l’accessibilité
En résumé, les API d’accessibilité évoluent : elles ne sont plus uniquement destinées aux humains, mais deviennent une couche d’interface clé pour les interactions entre l’IA et les systèmes

7. L’essor du travail asynchrone des agents

À mesure que les développeurs collaborent plus naturellement avec des agents de génération de code, la transition vers des workflows asynchrones s’accélère
- Les agents travaillent en parallèle en arrière-plan et rendent compte des résultats une fois un certain niveau d’avancement atteint
- Cette interaction se rapproche de plus en plus d’une orchestration de tâches (task orchestration) plutôt que du pair programming
- Autrement dit, le développeur transmet un objectif, l’agent l’exécute, puis le résultat est vérifié plus tard
Le point important n’est pas seulement d’alléger le travail, mais de compresser la collaboration elle-même
- Par exemple, au lieu de demander à une autre équipe une mise à jour de fichier de configuration, un triage d’erreurs ou un refactoring de composant,
  le développeur peut communiquer directement son intention à l’agent et lui demander de traiter cela en arrière-plan
- Là où il fallait auparavant des réunions synchrones, des handoffs entre équipes et de longs cycles de revue,
  une boucle requête → génération → validation (request → generate → validate) s’installe désormais naturellement
La façon d’interagir avec les agents s’élargit également
- Au-delà de la simple saisie de prompts dans un IDE ou un CLI, il devient possible de :
  - demander une tâche via un message Slack
  - laisser un commentaire sur une maquette Figma
  - ajouter des commentaires inline sur un diff de code ou une PR (ex. : l’assistant de revue Graphite)
  - ajouter du feedback sur la preview d’une application déployée
  - décrire oralement des changements via une interface vocale ou basée sur un appel
Ces évolutions font des agents une présence sur l’ensemble du cycle de vie du développement
- Ils ne se limitent plus à écrire du code : ils interprètent aussi le design, intègrent les retours et vont jusqu’au triage de bugs à l’échelle de la plateforme
- Le développeur endosse un rôle d’orchestrateur (orchestrator), en décidant quels fils de travail faire avancer, écarter ou fusionner
Cette dynamique suggère à terme que les fils de travail pilotés par des agents pourraient devenir le nouveau concept de « branche Git »
- Il ne s’agirait plus d’un fork de code statique, mais de fils dynamiques orientés objectif, exécutés de manière asynchrone puis intégrés une fois terminés

8. MCP : un pas de plus vers un standard universel pour le Model Context Protocol

Depuis la publication récente de cette analyse approfondie sur MCP, l’adoption de MCP s’accélère
OpenAI a officiellement adopté MCP, plusieurs nouvelles fonctionnalités ont été intégrées à la spécification,
et un nombre croissant de créateurs d’outils adoptent MCP comme interface par défaut entre les agents et le monde réel
MCP résout fondamentalement deux problèmes importants :
- fournir le contexte nécessaire pour qu’un LLM puisse exécuter même une tâche qu’il rencontre pour la première fois
- éliminer les intégrations sur mesure de type N×M et simplifier le tout en une structure où les outils exposent une interface standardisée (serveur), utilisable par tous les agents (clients)
L’adoption de MCP devrait encore s’élargir à l’avenir,
et avec l’émergence de MCP distant et d’un registre MCP de facto (de-facto registry),
de nombreuses applications pourraient être lancées avec une interface MCP intégrée par défaut
De la même manière que les API ont permis de connecter les outils SaaS et de composer des workflows,
MCP pourrait faire émerger un écosystème de composants interopérables pour les agents IA
Une plateforme qui intègre un client MCP n’est plus simplement « compatible IA »,
mais devient une partie d’un écosystème directement connectable à un réseau de fonctionnalités accessibles aux agents
Les clients et serveurs MCP ne sont que des concepts logiques, sans séparation physique stricte
- Cela signifie que n’importe quel client MCP peut devenir serveur, et inversement
- Cela ouvre la voie à une composabilité très avancée :
  - ex. : un agent de code peut récupérer des issues GitHub en tant que client et, en même temps, fournir à d’autres agents une couverture de tests ou des résultats d’analyse de code en tant que serveur
MCP est en train de s’imposer comme la couche d’interface fondamentale d’un écosystème où outils et agents interagissent de manière organique

9. Primitives abstraites : authentification, paiement et stockage dont tous les agents IA ont besoin

À mesure que les agents de vibe coding gagnent en puissance, une évidence s’impose :
ils peuvent générer beaucoup de code, mais ce code a besoin d’une base fiable à laquelle se connecter
De la même manière qu’un développeur humain s’appuie sur Stripe pour les paiements, Clerk pour l’authentification et Supabase pour la base de données,
les agents ont eux aussi besoin de primitives de service fiables et combinables
Ces services offrent des frontières d’API claires, des SDK faciles à utiliser et des paramètres par défaut raisonnables,
et jouent de plus en plus le rôle d’interface d’exécution pour les agents
Par exemple, lors de la création d’un outil qui génère une application SaaS, au lieu que l’agent implémente lui-même un système d’authentification ou une logique de paiement,
il peut intégrer Clerk et Stripe rapidement et de façon sûre
À mesure que ce modèle gagne en maturité, les services pourront aller au-delà de la simple exposition d’API et publier aussi :
- des schémas (schema) : définitions de données structurées
- des métadonnées de capacités (capability metadata) : spécifications des actions réalisables
- des example flows : exemples de méthodes d’intégration
  → permettant ainsi aux agents d’intégrer ces services de manière plus fiable
Certains services pourraient même être lancés avec un serveur MCP intégré
- ex. : Clerk pourrait exposer via un serveur MCP des fonctions comme la consultation de la liste des produits disponibles, la création d’un nouveau plan tarifaire ou la modification d’un abonnement
- Au lieu de chercher une spécification d’API ou de lire la documentation, l’agent formule une demande en langage naturel,
  et le serveur MCP valide et traite la requête dans les limites des permissions et des contraintes définies
- ex. :
  > « Crée un plan Pro à 49 $/mois et ajoute une facturation complémentaire basée sur l’usage »
  → le serveur MCP de Clerk interprète cette demande et l’exécute
De la même façon que rails new a permis un développement rapide aux débuts du web,
l’ère des agents a besoin de primitives fiables (drop-in identity, paiement, contrôle d’accès, etc.)
- elles doivent être suffisamment abstraites pour que les agents puissent les exploiter pour la génération,
  tout en reposant sur une architecture capable de passer à l’échelle avec la croissance de l’application

Conclusion

Ces 9 modèles montrent qu’il ne s’agit pas simplement d’ajouter l’IA aux méthodes de développement existantes, mais bien d’une redéfinition de la façon de produire des logiciels autour des agents, du contexte et de l’intention
En conséquence, les comportements traditionnels des développeurs évoluent eux aussi, et de nouvelles toolchains et de nouveaux protocoles (dont MCP) émergent rapidement pour les soutenir
Les couches d’outils fondamentales existantes, comme Git, les templates, les dashboards ou les méthodes de documentation, sont en train d’être repensées en profondeur avec l’IA
Dans cette phase de transition, on peut s’attendre à une forte activité de construction et d’investissement autour des outils et infrastructures de nouvelle génération qui composeront le nouvel écosystème du développement

8 commentaires

aa1567 2025-05-28

Il y a vraiment des gens qui font le n°1, en vrai..?

hhcrux 2025-05-27

Les LLM ne garantissent pas la même sortie pour une même entrée, donc ce genre de gestion de configuration fonctionne vraiment...?
Est-ce que c’est juste moi qui l’utilise encore de manière trop unidimensionnelle ?

beoks 2025-05-27

Je crois savoir qu’en définissant l’option temperature sur 0, on garantit la même sortie pour une même entrée.

fanotify 2025-05-28

De toute façon, dans quelques mois, le modèle lui-même aura encore changé, donc ça n’aura plus vraiment de sens, non ?

beoks 2025-05-27

En laissant cela de côté, je trouve bien trop catégorique le fait de ne même pas envisager une quelconque intervention humaine,
Pour de simples ajustements de chiffres ou de messages, l’intervention humaine serait pourtant plus efficace qu’un LLM.

nicewook 2025-05-26

C’est un texte qui offre une réflexion profonde. a16z, fidèle à sa réputation.

ruinnel 2025-05-26

https://fr.news.hada.io/topic?id=21091
Après avoir lu cet article, je me demande si c'est vraiment pertinent.

ahwjdekf 2025-05-26

Le point n°1 est vraiment cauchemardesque, un changement que je ne veux absolument pas accepter. En arriver à rendre inutile le suivi de l’historique du code source.