Découvrez comment AMP, l’agent de codage de pointe de Sourcegraph, façonne le paysage du développement IA grâce à l’itération rapide, au raisonnement autonome et aux agents capables d’appeler des outils — et pourquoi les outils de codage traditionnels deviennent obsolètes.
Le paysage des agents de codage IA connaît une disruption sans précédent. Ce qui était à la pointe il y a six mois est désormais dépassé. GitHub Copilot, autrefois la référence de l’assistance au développement par IA, a été éclipsé par de nouveaux outils. Cursor a dominé le marché en tant que startup à la croissance la plus rapide de tous les temps, pour finalement faire face à une concurrence encore plus avancée. Dans cet écosystème en évolution rapide, Sourcegraph a pris une décision stratégique audacieuse : plutôt qu’améliorer progressivement leur produit Cody existant, ils ont lancé AMP — un agent de codage entièrement nouveau, conçu dès le départ pour exploiter la frontière des capacités de l’IA.
Cet article explore la philosophie, l’architecture technique et la stratégie commerciale derrière AMP, avec des éclairages issus de discussions avec l’équipe à l’origine de cet outil révolutionnaire. Nous verrons pourquoi les approches traditionnelles du développement produit échouent à l’ère de l’accélération IA, en quoi les agents appelant des outils diffèrent fondamentalement des anciens assistants IA de codage, et à quoi ressemble le futur du développement autonome. Plus important encore, nous comprendrons pourquoi « l’empereur est nu » — pourquoi des produits établis, apparemment indétrônables, peuvent devenir hors-jeu du jour au lendemain lorsque la technologie sous-jacente évolue.
{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: L’empereur est nu – Pourquoi les agents de codage IA bouleversent les outils pour développeurs” class=“rounded-lg shadow-md” }}
L’évolution du développement assisté par IA suit une trajectoire claire : chaque génération se fonde sur la précédente, mais change fondamentalement la façon dont les développeurs interagissent avec l’intelligence artificielle. Pour comprendre l’importance d’AMP, il faut d’abord distinguer ce qui fait d’un agent de codage une nouvelle forme d’assistance IA. Le parcours a commencé avec GitHub Copilot, qui a introduit la complétion et la suggestion de code directement dans l’éditeur du développeur. Copilot était révolutionnaire car il intégrait l’IA dans le flux de travail de manière non intrusive, proposant des suggestions au fil de la frappe. Mais Copilot restait fondamentalement limité : il pouvait suggérer du code, mais pas exécuter des tâches complexes, multi-étapes, ni interagir avec l’environnement de développement dans son ensemble.
La génération suivante a vu l’émergence d’outils comme Cursor et Windsurf, qui ont adopté une approche différente en créant des forks d’IDE intégrant l’IA plus profondément dans l’environnement de développement. Ces outils ont démontré que des capacités partiellement agentiques — où l’IA pouvait réaliser des opérations plus complexes dans l’IDE — pouvaient considérablement améliorer la productivité des développeurs. Les développeurs étaient prêts à changer d’environnement si les capacités IA étaient suffisamment avancées. Pourtant, ces outils restaient limités : ils étaient interactifs, requérant l’approbation humaine à chaque étape, et ne pouvaient pas fonctionner de manière vraiment autonome.
Un agent de codage, à l’inverse, repose sur une architecture fondamentalement différente. Un agent se compose de trois éléments clés : un modèle de langage (typiquement un modèle de pointe comme Claude 3.5), un prompt système qui définit le comportement et les contraintes de l’agent, et un ensemble d’outils associés à des prompts qui décrivent leur fonctionnement. La différence essentielle réside dans la capacité des agents à interagir, avec des autorisations explicites, avec des systèmes externes — systèmes de fichiers, éditeurs de code, gestionnaires de versions, etc. Cela signifie qu’un agent peut raisonner de façon autonome sur un problème, choisir quels outils utiliser, les exécuter, observer les résultats et itérer jusqu’à accomplissement de la tâche. C’est fondamentalement plus puissant que toute approche précédente car cela permet un comportement véritablement autonome, au-delà de simples suggestions ou de l’assistance interactive.
Le paysage technologique est entré dans une phase d’instabilité sans précédent. Ce qui était à la pointe il y a dix-huit mois paraît aujourd’hui primitif. GitHub Copilot, lancé en 2021, a été une vraie révolution : c’était la première application grand public des grands modèles de langage au développement logiciel. Pourtant aujourd’hui, beaucoup de développeurs ne le citent même plus parmi les meilleures options d’assistance au codage par IA. Ce n’est pas parce que Copilot a régressé ; c’est parce que la technologie de base a progressé si vite que toute la catégorie a basculé. Ceci crée un défi de taille pour les entreprises établies : comment maintenir un produit à succès alors que le terrain se dérobe sous leurs pieds ?
Le développement produit traditionnel part du principe d’une base relativement stable. On trouve son product-market fit, on passe à l’échelle, on met en place des pratiques d’ingénierie robustes, on ajoute des fonctionnalités pour l’entreprise, on signe des contrats long terme. Cette recette a fonctionné des décennies durant car la technologie évoluait normalement par paliers. Or, à l’ère actuelle de l’IA, cette approche devient néfaste. Si vous optimisez votre produit pour la stabilité et la scalabilité, vous devenez lent. Si vous devenez lent, vous ratez la vague suivante d’avancées. Le temps d’ajouter les fonctionnalités d’entreprise et les cases de conformité sécurité, un nouveau modèle sort et rend votre approche obsolète.
Sourcegraph a été confronté à ce dilemme avec Cody. Cody était un produit à succès, avec des clients entreprise, des contrats longs, et des revenus conséquents. Mais Cody était fortement intégré à la plateforme Sourcegraph, donc soumis à ses cycles de publication. La plateforme avait sa propre infrastructure, son propre calendrier de déploiement, ses propres contraintes. Lorsque Claude 3.5 Sonnet a été publié et que l’équipe a vu qu’elle pouvait créer quelque chose de radicalement différent — un agent appelant des outils, capable de raisonnement autonome — elle a dû choisir : tenter d’intégrer ces capacités à Cody, ou repartir de zéro. Ils ont choisi de repartir de zéro, et cette décision révèle une leçon cruciale pour la compétition dans les marchés à évolution rapide.
La réalisation clé : il est impossible de rentabiliser un agent appelant des outils avec un abonnement à 20 $. Les coûts de calcul sont radicalement différents. Un assistant conversationnel comme Cody peut tourner efficacement sur une infrastructure modeste. Un agent appelant des outils, qui raisonne sur du code, exécute des outils et itère de façon autonome, exige bien plus de puissance de calcul. Ce n’est pas qu’un problème de prix ; c’est le signe que le produit est fondamentalement différent et requiert un autre modèle économique, d’autres attentes des clients et une stratégie de mise sur le marché différente. En créant AMP comme un produit séparé, avec une marque à part, Sourcegraph a pu redéfinir totalement les attentes. Ils peuvent dire aux clients : « Ceci n’est pas Cody 2.0. C’est un tout autre produit. Il coûte plus cher car il fait bien plus. Il fonctionne différemment car son architecture est différente. »
Pour vraiment saisir pourquoi AMP représente un changement de paradigme, il faut comprendre l’architecture technique des agents appelant des outils. Ce n’est pas simplement un modèle de langage avec accès à des fonctions. L’architecture est plus sophistiquée et puissante. Le système démarre avec un modèle de langage de pointe — pour AMP, Claude 3.5 Sonnet — entraîné à comprendre et utiliser les outils efficacement. Le modèle reçoit un prompt système qui définit son rôle, ses contraintes et ses objectifs. Ce prompt n’est pas une instruction anodine ; c’est un prompt soigneusement conçu qui façonne la manière dont le modèle raisonne et détermine les outils à utiliser.
En parallèle, chaque outil dispose de son propre prompt, décrivant ce que fait l’outil, les paramètres attendus, les valeurs de retour, et quand le solliciter. C’est crucial car le modèle doit comprendre non seulement qu’un outil existe, mais aussi à quoi il sert et quand l’utiliser à bon escient. Par exemple, un agent peut disposer d’outils pour lire des fichiers, écrire, exécuter du code, lancer des tests, enregistrer des modifications. Chaque outil est décrit en détail pour aider le modèle à raisonner sur le choix à faire selon la situation. Le modèle peut alors décider de recourir à ces outils, observer les résultats, et itérer sur la base de ce qu’il apprend.
La puissance de cette architecture devient évidente quand on considère ce qu’un agent peut accomplir. Un développeur peut demander à l’agent « implémente une nouvelle fonctionnalité d’authentification utilisateur dans cette base de code ». L’agent pourra alors, de façon autonome : lire la base de code existante, identifier où intégrer l’authentification, écrire le code nécessaire, lancer les tests, corriger les échecs, et finalement committer les changements. Tout cela sans intervention humaine. L’agent raisonne, choisit ses outils, et itère en fonction des retours.
C’est radicalement différent des anciens outils IA de codage. Copilot suggère du code, mais ne peut exécuter un workflow multi-étapes. Cursor peut aller plus loin, mais requiert l’approbation humaine à chaque étape. Un agent, lui, peut agir de façon autonome avec des permissions explicites. Cela ouvre une nouvelle catégorie de capacités, d’un ordre de grandeur supérieur. Mais cela soulève aussi de nouveaux défis : des agents autonomes peuvent faire des erreurs à grande échelle, exécuter des opérations nuisibles s’ils ne sont pas bien contraints, nécessitent un prompt système soigné pour garantir leur bon comportement. D’où l’importance de l’architecture et de l’approche d’AMP.
Dès le début, l’équipe AMP a fait un choix fondamental : la vitesse et l’itération seraient la priorité. Tout découle de cette décision. Cela impliquait d’abandonner de nombreuses pratiques qui avaient fait le succès de Cody : pas de revues de code formelles, pas de cycles de planification longs, pas de checklists sécurité et conformité sur neuf mois. À la place, ils ont adopté une mentalité de projet perso : push direct sur main, 15 mises en production par jour, dogfooding constant, itération basée sur l’usage réel.
Cette approche peut sembler chaotique, et pour l’ingénierie logicielle traditionnelle, elle l’est. Mais elle est parfaitement adaptée à un produit qui évolue à la frontière des capacités IA. La raison est simple : la frontière bouge. Tous les quelques mois, un nouveau modèle sort. Toutes les semaines, de nouvelles capacités émergent. Tous les jours, de nouvelles techniques de prompt engineering ou de design d’outils sont découvertes. Dans ce contexte, la capacité à itérer vite compte plus que la capacité à scaler de façon fiable. Un produit qui shippe 15 fois par jour peut intégrer de nouvelles capacités de modèle en quelques heures. Un produit au rythme traditionnel aura des mois de retard.
La structure d’équipe reflète cette philosophie. L’équipe AMP est petite — environ huit personnes — comparée aux grands services d’ingénierie. Cette taille réduite est voulue : elle permet des décisions rapides et élimine la lourdeur de communication qui ralentit les grandes équipes. Tous sont expérimentés, donc peuvent travailler sans processus de revue de code extensif. Ils dogfoode le produit en permanence, ce qui leur permet de détecter rapidement les problèmes et de comprendre les besoins utilisateurs de l’intérieur. Ils ne cherchent pas à faire un produit pour tous les développeurs ; ils s’adressent à ceux qui veulent aller aussi vite qu’eux, rester à la pointe de l’IA, et adopter de nouvelles façons de travailler.
Ce positionnement est crucial. AMP ne cherche pas à être le Copilot de tout le monde. Il ne vise pas à devenir l’outil IA par défaut pour tous les développeurs. Il se positionne comme l’outil des développeurs et équipes qui veulent avancer vite et rester à la frontière. Ce marché est bien plus restreint que « tous les développeurs », mais il est prêt à payer beaucoup plus pour des capacités supérieures. Le modèle économique reflète cela : au lieu d’un abonnement à 20 $ par mois, les clients AMP paient des centaines de dollars par mois. Certaines équipes atteignent des taux annuels de plusieurs centaines de milliers de dollars. C’est possible car la proposition de valeur est très forte pour le public visé.
Les principes qui guident le développement d’AMP — itération rapide, positionnement de pointe, raisonnement autonome — sont directement applicables à l’automatisation des workflows. FlowHunt, en tant que plateforme de création et d’automatisation de workflows complexes, fait face à des défis et opportunités similaires. Tout comme AMP se positionne pour exploiter la prochaine génération de capacités IA, FlowHunt aide les organisations à bâtir des workflows résilients dans un contexte technologique mouvant. En misant sur la flexibilité, l’itération rapide et la capacité d’intégrer rapidement de nouveaux outils et capacités, FlowHunt permet aux équipes de garder une longueur d’avance.
La clé, c’est que dans un paysage technologique en rapide évolution, la capacité à s’adapter vaut mieux que l’optimisation du présent. Que vous construisiez un agent de codage IA ou que vous automatisiez des processus métiers, cette logique prévaut. L’approche FlowHunt, centrée sur la création rapide, le test et l’itération des workflows, s’accorde parfaitement avec cette philosophie. Les équipes peuvent intégrer les dernières capacités IA, tester rapidement, itérer selon les résultats. À mesure que de nouveaux modèles et outils apparaissent, les workflows peuvent être mis à jour rapidement, sans refonte complète. C’est l’avenir de l’automatisation : non pas des process statiques et optimisés, mais des workflows dynamiques et adaptatifs, évoluant avec la technologie.
Le marché des agents de codage IA est un cas d’école sur la rapidité avec laquelle le leadership peut changer. Début 2024, Cursor était le roi incontesté des outils de codage IA. La startup à la croissance la plus rapide, des développeurs quittant massivement la concurrence. Le marché semblait figé. Puis, en quelques mois, la conversation a changé. De nouveaux outils sont apparus. Les capacités ont progressé. Les développeurs ont commencé à se poser d’autres questions. À la mi-2024, si vous demandiez quel était le meilleur outil, beaucoup ne citaient plus Cursor en premier. Le marché s’est déplacé si vite que le leader d’hier ne dominait plus.
Ce schéma n’est pas propre aux agents de codage. C’est une caractéristique fondamentale des marchés où la technologie progresse rapidement. Dans de tels marchés, la capacité à bouger vite et à s’adapter compte davantage que la part de marché actuelle. Une entreprise avec 30 % de parts de marché mais qui itère vite finira par dépasser celle qui en a 50 % mais avance lentement. C’est pourquoi la décision de Sourcegraph de créer AMP comme produit séparé est si pertinente. En séparant AMP de Cody, ils se sont affranchis des contraintes qui les auraient ralentis. Ils peuvent avancer vite, itérer rapidement, et rester à la pointe.
La leçon générale, c’est que dans les marchés en évolution rapide, l’empereur est souvent nu. Les produits établis, en apparence indéboulonnables, peuvent devenir obsolètes très vite. Ce n’est pas qu’ils empirent, c’est que la technologie évolue et qu’ils n’arrivent pas à s’adapter. Les entreprises qui réussissent sont celles qui comprennent cette dynamique et se positionnent en conséquence. Elles n’optimisent pas pour le présent, mais pour leur capacité à s’adapter. Elles ne cherchent pas à servir tout le monde, mais ciblent ceux qui valorisent la vitesse et l’innovation. Elles ne suivent pas les process traditionnels, mais adoptent des pratiques qui permettent l’itération rapide et l’apprentissage.
La discussion autour d’AMP révèle un point clé sur l’avenir des agents IA : le prochain grand saut sera le passage des agents interactifs aux agents asynchrones. Aujourd’hui, la plupart des agents de codage IA fonctionnent de façon interactive. Un développeur lance un agent dans son éditeur ou en ligne de commande, l’agent opère, le développeur voit le résultat. Il y a typiquement un agent en marche à la fois, en mode synchrone : on attend la fin de l’opération. C’est déjà un bond par rapport au codage manuel, mais ce n’est pas le summum du développement assisté par agent.
La prochaine frontière, ce sont les agents asynchrones, fonctionnant 24/7 en arrière-plan, en parallèle. Plutôt qu’un seul agent à la fois, vous pourriez en avoir 10, 50, 100 tournant simultanément sur des tâches distinctes. Un agent peut refactorer une partie du codebase pendant qu’un autre écrit des tests ailleurs. Un troisième analyse la performance et propose des optimisations. Tout cela sans intervention humaine, et en parallèle. Les implications sont énormes : un gain de productivité de 10 à 100 fois, un bouleversement des équipes de développement, une réinvention du possible avec l’IA.
Ce changement aura un fort impact sur les coûts d’inférence, la façon d’organiser le travail, la définition même du métier de développeur. Il posera aussi de nouveaux défis en matière de qualité, de sécurité, et de maîtrise des bugs à grande échelle. Mais le potentiel est immense. Les équipes capables de tirer parti des agents asynchrones pourront accomplir en jours ce qui prenait des semaines. D’où l’importance d’être capable de bouger vite et de s’adapter. Les entreprises qui réussiront à construire des agents asynchrones efficaces auront un avantage concurrentiel colossal.
La philosophie d’AMP repose sur un principe fondamental : construire pour l’incertitude. L’équipe ignore où ira exactement la technologie, mais sait qu’elle évoluera. Elle ne sait pas quelles capacités compteront le plus, mais sait que de nouvelles émergeront. Elle ne sait pas à quoi ressemblera le marché dans six mois, mais sait qu’il sera différent. Face à cette incertitude, la bonne démarche n’est pas d’optimiser, mais de maximiser l’adaptabilité : garder une base de code flexible, la capacité de shipper vite, rester à la pointe de l’IA, et accepter de jeter ce qui ne marche plus.
Ce principe s’applique aussi à la structure d’équipe, au business model, à la stratégie client. L’équipe est petite et expérimentée, permettant des décisions rapides. Le modèle économique est flexible, sans tarification ou modèle utilisateur figé, ce qui facilite l’ajustement. La stratégie client vise les développeurs qui veulent avancer vite, alignant ainsi capacités de l’entreprise et attentes du marché. Tout découle de ce principe : construire pour l’incertitude, optimiser pour l’adaptabilité.
C’est une approche radicalement différente du développement produit traditionnel, où l’on cherche à prédire l’avenir, à scaler, à viser la stabilité. Mais dans un marché où la technologie progresse vite, ces recettes sont néfastes : elles ralentissent, enferment dans des choix rapidement obsolètes, empêchent d’adapter l’organisation. Les entreprises qui réussissent sont celles qui embrassent l’incertitude, optimisent l’adaptabilité, et avancent assez vite pour garder l’avantage.
{{ cta-dark-panel heading=“Boostez votre workflow avec FlowHunt” description=“Découvrez comment FlowHunt automatise vos workflows IA et SEO — de la recherche à la génération de contenu, jusqu’à la publication et l’analyse — tout-en-un.” ctaPrimaryText=“Réserver une démo” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Essayez FlowHunt gratuitement” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}
La capacité à déployer 15 fois par jour n’est pas fortuite ; c’est le fruit de choix architecturaux délibérés. Première décision clé : découpler totalement AMP de la plateforme Sourcegraph. Cody était intégré de près à Sourcegraph, donc soumis à ses cycles de publication et à ses contraintes d’infrastructure. AMP a été conçu comme un produit autonome, avec sa propre infrastructure, son pipeline de déploiement, son calendrier de sorties. Ce découplage est fondamental car il élimine la coordination chronophage des grands systèmes. Les changements AMP ne nécessitent pas d’attendre la plateforme, ni d’en coordonner les releases.
Deuxième décision : adopter un processus de revue de code minimal. L’équipe push sur main et shippe souvent. Si un bug survient, il est corrigé rapidement. Cela semble risqué, mais fonctionne car l’équipe est petite, expérimentée et dogfoode le produit. Les problèmes sont détectés vite car ils l’utilisent eux-mêmes. Ils réagissent vite car le code est frais dans leur esprit. Ils itèrent vite car ils n’attendent pas d’approbation. Cette méthode serait dangereuse dans une grande organisation, mais sur une petite équipe experte, elle est très efficace.
Troisième décision : dogfooder le produit à l’extrême. L’équipe utilise AMP pour développer AMP. Cela crée une boucle de feedback serrée où chaque problème ou limite est ressenti immédiatement. Cela permet aussi de découvrir de nouveaux cas d’usage. Utiliser son propre produit pour se construire soi-même permet d’identifier rapidement ce qui fonctionne ou pas, de découvrir des cas limites, de voir quelles fonctionnalités sont cruciales. C’est la force du dogfooding pour l’itération rapide.
Quatrième décision : garder la base de code simple et flexible. Plutôt que de viser la complexité ou l’optimisation extrême, l’équipe construit un système facile à modifier et à étendre. Cela permet d’intégrer rapidement de nouvelles capacités. Lorsqu’un nouveau modèle sort, il peut être intégré vite. Lorsqu’une nouvelle technique de prompt engineering émerge, on peut expérimenter rapidement. Lorsqu’une meilleure approche est trouvée, on refactore sans craindre de casser des dépendances complexes. Cette simplicité et flexibilité valent mieux que l’optimisation dans un marché en mutation rapide.
Le modèle de tarification d’AMP illustre bien la création de valeur dans le développement assisté par IA. Très tôt, l’équipe a compris qu’un abonnement à 20 $/mois n’était pas viable pour un agent appelant des outils. Ce n’est pas qu’une question de tarification — c’est le signe que le produit est d’une autre nature et requiert un business model différent. Un assistant conversationnel comme Cody tourne sur une infrastructure modeste. Un agent appelant des outils, qui raisonne, exécute des outils, itère de façon autonome, consomme beaucoup plus de ressources. Les coûts d’infrastructure seuls justifient un prix plus élevé.
Mais le modèle de prix reflète aussi la valeur créée. Pour un développeur ou une équipe qui exploite bien AMP, les gains de productivité sont énormes. Un agent capable d’implémenter des fonctionnalités, d’écrire des tests, de refactorer du code de façon autonome peut faire gagner des heures, voire des jours de travail par semaine. Pour une équipe, cela se traduit en valeur tangible. Si AMP fait gagner 10 heures par semaine à une équipe, et qu’une heure de développeur coûte 100 $, cela fait 1 000 $ de valeur créée par semaine. Facturer quelques centaines de dollars par mois est donc une fraction minime de la valeur délivrée. C’est ainsi que certaines équipes atteignent des taux annuels de plusieurs centaines de milliers de dollars : la valeur créée est telle que le prix est une aubaine.
Le modèle économique reflète aussi le positionnement stratégique. En demandant bien plus que les outils de codage traditionnels, AMP signale qu’il appartient à une autre catégorie. Il ne concurrence pas sur le prix, mais sur la capacité et la valeur. Cela attire des clients qui valorisent ces critères, et écarte les clients purement sensibles au prix. C’est exactement la segmentation souhaitable pour un produit à la frontière de l’IA. On veut des clients qui comprennent la valeur de ces capacités et sont prêts à payer pour. On ne veut pas de clients cherchant juste le moins cher, qui partiront au prochain outil low cost.
L’un des aspects les plus intéressants de l’approche Sourcegraph est la gestion de la tension entre innovation et stabilité. Sourcegraph a une activité rentable avec Cody et sa plateforme. Ce business génère des revenus qui financent l’expérimentation radicale d’AMP. Mais cela crée aussi une tension organisationnelle : comment maintenir un business stable tout en poursuivant l’innovation radicale ? Comment garder les meilleurs ingénieurs focalisés sur le nouveau produit alors qu’ils ont une grande expertise sur l’existant ?
La réponse implique plusieurs décisions clés. D’abord, Sourcegraph a choisi de ne pas essayer de convertir les clients Cody vers AMP. Ils utilisent la confiance et les revenus de Cody pour financer AMP. C’est fondamental : tenter de migrer les clients Cody vers AMP aurait généré de la résistance, car AMP est fondamentalement différent et requiert d’autres usages. En gardant Cody et AMP séparés, ils servent des segments différents et évitent la perturbation d’une migration forcée.
Ensuite, Sourcegraph a réuni une équipe AMP composée de personnes sans a priori sur le développement logiciel. Certains membres n’ayant travaillé que dans de micro-structures. Ils n’ont pas des années d’habitudes sur les revues de code, la planification, l’optimisation. Cette absence de « bagage » est un atout : ils peuvent adopter des pratiques radicales pour quelqu’un de plus traditionnel, sans dissonance cognitive.
Enfin, Sourcegraph a explicitement formulé des règles différentes pour AMP. L’équipe ne suit pas les mêmes process que le reste de l’entreprise : pas de revues de code formelles, pas de checklists sécurité/conformité, pas les mêmes cycles de planification. C’est possible grâce à la confiance client : ils savent qu’AMP est un produit de pointe, acceptent d’autres compromis. Cette séparation explicite est cruciale. Si AMP devait suivre les process du reste de Sourcegraph, il serait ralenti. La séparation crée un espace pour l’innovation radicale.
L’histoire d’AMP offre plusieurs leçons pour les organisations dans des marchés évolutifs. Première leçon : le succès établi peut devenir un handicap. La réussite de Sourcegraph avec Cody aurait pu les enfermer dans une démarche incrémentale. Au contraire, ils ont vu le changement technologique arriver et ont eu le courage de repartir de zéro, quitte à cannibaliser leur business, sachant que l’ancienne approche ne marcherait plus.
Deuxième leçon : dans des marchés mouvants, la vitesse et l’adaptabilité valent plus que l’optimisation et le passage à l’échelle. L’équipe ne cherche pas à construire le système parfait, mais un système suffisant et évolutif. Elle ne cherche pas à satisfaire tout le monde, mais cible ceux qui veulent aller vite et innover. Elle ne suit pas les process traditionnels, mais adopte ceux qui permettent l’itération rapide. Miser sur l’adaptabilité plutôt que l’optimisation est contre-intuitif, mais adapté à la vitesse du progrès technologique actuel.
Troisième leçon : les petites équipes expérimentées peuvent surpasser les grandes organisations. L’équipe AMP compte environ huit personnes, toutes expérimentées. Elles travaillent sans revues de code formelles, sans planification lourde, déploient 15 fois par jour, dogfoode le produit en continu. Cette petite équipe va plus vite et innove plus efficacement que de grandes équipes ailleurs, car elle élimine les lourdeurs de communication et de processus.
Quatrième leçon : il faut redéfinir les attentes quand le produit évolue radicalement. Les clients Cody avaient des attentes sur les prix, les fonctionnalités, le fonctionnement du produit. Ces attentes n’auraient pas convenu à AMP. En créant AMP comme produit séparé, Sourcegraph a pu redéfinir les attentes. C’est une stratégie puissante quand votre produit est radicalement différent de l’ancien. Plutôt que de modifier l’ancien produit, créez-en un nouveau et repartez sur de nouvelles bases.
Le marché des agents de codage IA est marqué par le changement rapide et la volatilité du leadership. À un instant donné, il y a un « meilleur » outil, mais cette position est instable. Copilot a été leader, Cursor aussi. Désormais, plusieurs concurrents sont forts et la place de leader est disputée. Cette instabilité vient du progrès rapide des modèles et techniques sous-jacentes. Quand Claude 3.5 Sonnet est sorti, il a permis de nouveaux usages. Quand de nouvelles techniques de prompt engineering apparaissent, elles sont vite intégrées. À chaque sortie de modèle, le paysage concurrentiel évolue.
Dans ce contexte, ceux qui réussissent sont ceux qui bougent et s’adaptent vite. Une entreprise optimisée pour la stabilité sera lente à intégrer de nouvelles capacités. Une entreprise optimisée pour la vitesse saura le faire rapidement. Avec le temps, la rapide prendra l’avantage. Voilà pourquoi l’accent mis par AMP sur la vitesse et l’itération est si stratégique. En s’optimisant pour la vitesse, AMP se donne les moyens de rester en tête à mesure que la technologie évolue.
Le marché voit aussi se renforcer la spécialisation. Au lieu de viser tous les développeurs, les produits à succès se concentrent sur des segments. AMP cible ceux qui veulent bouger vite et rester à la pointe. D’autres produits misent sur l’entreprise, la stabilité et le support. D’autres sur les débutants, l’éducation. Cette spécialisation est saine, car elle permet d’optimiser l’offre pour son segment plutôt que de vouloir tout faire.
L’histoire d’AMP révèle des vérités fondamentales sur la compétition dans les marchés évolutifs. Les produits établis, en apparence indétrônables, peuvent devenir obsolètes très vite quand la technologie évolue. Les entreprises optimisées pour la stabilité et l’échelle deviennent lentes et vulnérables. Celles qui misent sur la vitesse et l’adaptabilité vont assez vite pour rester devant. L’empereur est souvent nu : le produit dominant d’aujourd’hui peut devenir hors-jeu demain s’il n’évolue pas. Le choix de Sourcegraph de créer AMP à part, d’adopter des pratiques radicales (push direct, pas de revue de code), de privilégier la vitesse et l’itération sur l’optimisation, et de viser la frontière des capacités IA, reflète une compréhension fine des enjeux de ces marchés. Les leçons d’AMP vont bien au-delà du codage IA. Toute organisation opérant dans un marché où la technologie avance vite devrait se demander si elle optimise pour les bons critères : Optimisez-vous pour la stabilité alors qu’il faudrait viser l’adaptabilité ? Essayez-vous de satisfaire tout le monde au lieu de cibler un segment précis ? Suivez-vous les process traditionnels alors que l’itération rapide est clé ? Les réponses à ces questions détermineront si votre organisation prospère — ou devient obsolète — face au changement technologique.
AMP est un agent de codage de pointe développé par Sourcegraph qui utilise des modèles de langage avancés avec des capacités d’appel d’outils pour raisonner et exécuter des modifications de code de façon autonome. Contrairement à Cody, qui était fortement intégré à la plateforme Sourcegraph et limité par ses cycles de publication, AMP fonctionne de manière indépendante avec sa propre infrastructure, permettant plus de 15 déploiements par jour et une itération rapide sur les nouvelles capacités des modèles.
Sourcegraph a créé AMP comme produit distinct pour éviter de perturber les contrats d’entreprise existants et les attentes des clients autour de Cody. Le passage d’un assistant conversationnel à un agent capable d’appeler des outils constitue un changement fondamental dans la façon dont les développeurs interagissent avec l’IA. En créant une nouvelle marque et un nouveau produit, Sourcegraph a pu redéfinir les attentes, accélérer sans les contraintes du passé et se positionner à la pointe du développement IA sans aliéner sa clientèle existante.
Les agents appelant des outils sont des systèmes IA qui combinent un modèle de langage, des prompts système et des outils externes pour réaliser des tâches de façon autonome. Contrairement aux chatbots traditionnels, ces agents peuvent interagir avec des systèmes de fichiers, des éditeurs de code et d’autres systèmes externes avec des autorisations explicites. Cela leur permet d’exécuter de façon autonome des workflows complexes et multi-étapes, les rendant fondamentalement plus puissants pour les tâches de développement logiciel.
AMP connaît une croissance de plus de 50 % mois après mois, certaines équipes atteignant des taux annuels de plusieurs centaines de milliers de dollars. Le produit affiche des marges brutes positives tout en maintenant ce rythme de croissance. Sourcegraph cible stratégiquement les développeurs qui souhaitent avancer vite et rester à la pointe des modèles, plutôt que de convaincre chaque développeur d’une entreprise.
La discussion met en avant que les agents asynchrones fonctionnant 24/7 en arrière-plan domineront la prochaine phase du développement IA. Au lieu d’agents interactifs lancés un par un dans un éditeur, les équipes exécuteront de 10 à 100 agents simultanément et de façon autonome, multipliant par 10 à 100 la productivité et l’inférence. La clé du succès : positionner son produit pour évoluer vite et s’adapter à l’émergence de nouveaux modèles et capacités tous les quelques mois.
Arshia est ingénieure en workflows d'IA chez FlowHunt. Avec une formation en informatique et une passion pour l’IA, elle se spécialise dans la création de workflows efficaces intégrant des outils d'IA aux tâches quotidiennes, afin d’accroître la productivité et la créativité.
Découvrez comment FlowHunt aide les équipes à construire, tester et déployer des workflows IA plus rapidement que jamais.
Découvrez les capacités révolutionnaires de Claude Sonnet 4.5, la vision d'Anthropic pour les agents IA, et comment le nouveau SDK Claude Agent redéfinit le fut...
Découvrez comment l'apprentissage par renforcement et l'affinage sont devenus la méthode dominante pour optimiser les modèles d'IA, de la distillation de GPT-4 ...
Découvrez les annonces d’OpenAI lors du DevDay 2025, dont les Apps SDK, Agent Kit et le Model Context Protocol. Comprenez pourquoi le prompting est plus crucial...
Consentement aux Cookies
Nous utilisons des cookies pour améliorer votre expérience de navigation et analyser notre trafic. See our privacy policy.
