Refonte agentique : faut-il reconstruire son logiciel ?

En résumé

• Beaucoup d’éditeurs de logiciel installés se demandent s’ils doivent reconstruire leur produit en IA agentique (agentic-first) ou faire évoluer leur existant.
• Sur huit critères, aucune approche ne l’emporte partout : l’évolution progressive garde l’avantage sur la logique métier, la conformité et la base installée ; la refonte l’emporte sur la vitesse de livraison et l’adaptation à chaque utilisateur.
• Le critère décisif est souvent la réversibilité : l’approche progressive permet de basculer plus tard, workflow par workflow ; la refonte complète referme cette porte.

Trois forces poussent aujourd’hui un éditeur de logiciel installé à se poser la question. La concurrence de nouveaux entrants qui livrent plus vite. La baisse du coût de développement permise par le code assisté par l’IA. Et l’attente d’investisseurs qui veulent une histoire IA crédible. D’où la tentation : repartir de zéro en IA agentique, ou faire évoluer un existant parfois lourd à porter ?

Cette refonte agentique porte une double promesse : un développement plus simple et moins coûteux, et une utilité renouvelée pour le client. Chacune mérite d’être vérifiée avant d’être adoptée comme une évidence.

Les chiffres disponibles invitent à la prudence. Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027, en raison de coûts qui dérapent, d’une valeur métier floue ou d’une maîtrise des risques insuffisante. Le constat n’est pas propre à l’agentique : RAND estime que plus de 80 % des projets d’IA échouent, soit deux fois plus que les projets informatiques classiques, et le MIT observe que seuls 5 % des pilotes d’IA générative en entreprise produisent un effet mesurable sur le compte de résultat. Le risque d’exécution est réel, et il doit être pesé consciemment.

Dans ce qui suit, deux approches se font face. L’approche progressive : l’éditeur garde son existant et y ajoute des capacités agentiques. L’approche de rupture : il le démantèle pour repartir sur une architecture agentique, ou un nouvel entrant naît directement sur ce modèle. Mais ce que chaque critère signifie dépend d’abord d’un arbitrage qu’aucune des deux ne contrôle entièrement : celui du client, qui répond à chaque fois en choisissant de rester, de changer ou d’attendre.

1. Donnée propriétaire et historique client : un avantage difficile à reconstituer

Approche progressive. Elle préserve nativement ce qui s’est accumulé avec le temps : l’historique client, les paramétrages spécifiques, les exceptions gérées au fil des années. Elle n’a rien à reconquérir et part de ce qui existe déjà. Elle facilite aussi l’appropriation par les équipes techniques, produit et service client.

Approche de rupture. La donnée brute se migre relativement bien aujourd’hui : un datalake absorbe l’historique sans difficulté majeure. Ce qui résiste, c’est la logique métier qui s’est affinée autour d’elle : règles de gestion, workflows rodés par l’usage, exceptions traitées au cas par cas. Rarement documentée, elle vit dans le code de l’ancien système, et la reconstruire dans une architecture agentique prend nettement plus de temps, avec plus d’incertitude, qu’un simple transfert de données. Un nouvel entrant n’a ni cette donnée ni cette logique à reconstituer, mais pas non plus cet historique à mobiliser : il doit compenser en collectant rapidement de la donnée d’usage, ou via des partenariats d’intégration.

C’est l’un des critères où l’avantage de l’approche progressive reste difficile à égaler rapidement. On le retrouve d’ailleurs parmi ce qui reste défendable pour un éditeur face aux agents généralistes.

2. Conformité et responsabilité réglementaire : un acquis, pas une garantie universelle

Approche progressive. Elle hérite d’un existant déjà validé : les règles de paie, les obligations déclaratives, les contrôles comptables ont été éprouvés et corrigés au fil des années d’usage réel. La conformité n’est pas à prouver à nouveau : elle est dans le produit, et dans les pratiques des équipes qui le maintiennent.

Approche de rupture. Elle doit tout revalider. Et un système agentique ajoute une question que les systèmes déterministes ne posaient pas : quand une décision autonome produit une erreur réglementée (paie mal calculée, écriture comptable incorrecte, destruction accidentelle de données), la responsabilité reste à établir, alors qu’elle était déjà tranchée pour un système classique.

Un incident survenu en juillet 2025 l’illustre, hors de tout périmètre réglementé. Lors d’un test mené par le fondateur de SaaStr, l’agent de développement de Replit a supprimé une base de données de production malgré une consigne explicite de ne plus rien modifier sans validation, puis a tenté de masquer son erreur. Le dirigeant de Replit a reconnu un incident « inacceptable » et déployé de nouveaux garde-fous dans la foulée. Dans un environnement soumis à obligation légale, les conséquences seraient d’une autre nature. Nous avions détaillé ces risques propres à l’IA agentique dans un précédent article.

Un nouvel entrant porte le même fardeau de validation, sans l’expérience accumulée sur les cas limites. Il peut en revanche construire sa conformité dès la conception, sans héritage à concilier avec de nouvelles contraintes.

Ce critère reste favorable à l’approche progressive, avec une nuance importante : il ne protège que les workflows soumis à une obligation réglementaire précise. Un workflow sans enjeu de conformité n’en bénéficie pas.

3. Vitesse de déploiement et coût de développement : l’avantage le plus net de la rupture

Approche progressive. Elle doit composer avec l’existant à chaque nouvelle fonction : préserver la compatibilité, tester les interactions avec le reste du système, respecter des cycles de validation déjà en place. Chaque avancée est plus sûre, mais aussi plus lente à livrer.

Approche de rupture. Elle n’a pas cette contrainte. Conçue directement pour l’agentique, sans compatibilité à préserver ni héritage à ménager, elle réduit le temps et le coût de développement. L’écart entre Cursor et GitHub Copilot illustre ce mécanisme. Copilot disposait de tous les avantages structurels : premier arrivé, adossé à Microsoft, intégré nativement à l’écosystème GitHub. Cursor, structure bien plus petite, s’est pourtant imposé en peu de temps comme l’un des assistants de code les plus utilisés, en livrant plus vite les fonctions attendues par les développeurs : contexte à l’échelle du dépôt, édition multi-fichiers, commandes en langage naturel.

C’est le critère où la balance penche le plus nettement du côté de la rupture, et probablement la raison principale pour laquelle cette option est souvent envisagée en premier. Cette absence de friction a pourtant un revers dans la durée : les évolutions se déploient plus vite, mais avec moins de garde-fous, ce qui augmente le risque de régression à chaque changement. La maintenance d’une architecture agentique est plus rapide, mais moins prévisible.

4. Coût de changement pour le client : un bouclier sur la base acquise, pas sur les prospects

Approche progressive. Elle bénéficie d’un verrou sur sa base installée : un client déjà équipé a investi du temps de formation, de paramétrage, d’intégration avec ses autres outils. Changer de solution représente pour lui un coût et un risque réels, ce qui protège mécaniquement l’éditeur en place.

Approche de rupture. Ce verrou ne joue aucun rôle face à un nouveau prospect. Un client qui n’a encore rien choisi ne compare pas un coût de changement : il compare deux offres sur leurs mérites respectifs. Sur ce terrain, la rupture peut se montrer plus rapide ou plus simple à adopter.

La bataille se déplace. L’éditeur installé défend sa base existante presque par défaut, mais doit gagner chaque nouveau client comme s’il n’avait aucun avantage acquis. À l’inverse, un éditeur qui bascule sa propre base vers la rupture prend le risque opposé : transformer des clients fidélisés en vulnérabilité temporaire, le temps de la migration.

5. Largeur fonctionnelle ou profondeur ciblée : une question de terrain d’attaque

Approche progressive. Elle tend à tout couvrir par accumulation : année après année, elle a répondu aux demandes des clients jusqu’à traiter un métier dans sa quasi-totalité. C’est un atout réel face à un client qui ne veut pas jongler entre plusieurs outils.

Approche de rupture. Elle ne cherche pas à reconstruire cette largeur d’un coup. Elle concentre son effort sur des workflows précis, souvent nouveaux et à forte douleur, et vise à y être nettement meilleure que la solution en place sur ce périmètre limité. L’émergence de Rillet et Numeric dans la comptabilité en donne une illustration : des éditeurs récents qui proposent des workflows de clôture et de reporting pensés nativement pour l’automatisation, sur un périmètre que des acteurs plus larges couvrent sans l’avoir optimisé au même niveau.

La question pour un éditeur installé n’est donc pas de savoir s’il sera concurrencé en bloc, mais sur quelle fonction précise un concurrent spécialisé peut faire nettement mieux. C’est là que la rupture cherche à s’implanter en premier, et aucune des deux approches n’a d’avantage structurel : tout dépend de la fonction attaquée.

6. Ancrage dans les workflows du client : la personnalisation, au prix de la fiabilité

Approche progressive. Elle dispose d’un ancrage opérationnel réel : le client l’ouvre chaque jour, ses équipes la connaissent, ses écrans font partie de la routine. Mais cet ancrage reste générique : les mêmes workflows s’appliquent à tous les utilisateurs d’un même profil, sans s’adapter à chacun.

Approche de rupture. Elle vise un ancrage plus profond, parce qu’elle peut s’adapter à chaque utilisateur plutôt qu’à un profil type. Cela peut prendre la forme d’un agent conversationnel qui apprend les habitudes d’une personne précise, de workflows construits à partir de sa configuration exacte, ou d’une capacité à analyser un problème ouvert qu’aucun profil type n’aurait anticipé.

Cet avantage reste conditionné à la fiabilité d’exécution. La capacité de raisonnement ouvert explique à la fois la force de la promesse agentique et les taux d’échec évoqués plus haut : elle traite des cas qu’aucun workflow prédéfini n’aurait couverts, mais c’est aussi la plus difficile à fiabiliser à grande échelle.

7. Structure financière : deux natures de risque, pas de vainqueur désigné

Approche progressive. Elle s’appuie sur un compte de résultat mature : un chiffre d’affaires récurrent, une base de clients qui paie, une capacité à financer la transformation sur plusieurs années. Les investisseurs jugent souvent un éditeur SaaS à l’aune de la règle des 40 (taux de croissance + marge ≥ 40 %), un seuil que la marge brute élevée du logiciel classique aide à atteindre.

Approche de rupture. Portée par un nouvel entrant, elle repose souvent sur du capital levé plutôt que sur des revenus établis. Ce capital impose sa propre pression : démontrer une traction rapide pour justifier le tour suivant, sur un horizon de mois plutôt que d’années. S’y ajoute le coût de l’inférence, qui pèse directement sur la rentabilité : Bessemer Venture Partners situe la marge brute des produits IA autour de 50 à 60 %, contre 80 à 90 % pour le SaaS classique. Nous avons analysé cette érosion de la marge et ses effets sur la valeur d’un éditeur dans un article dédié.

Les cas les plus spectaculaires poussent la logique encore plus loin. Dans son State of AI 2025, Bessemer décrit des startups IA à croissance fulgurante (dont Cursor fait partie) qui atteignent en moyenne 40 millions de dollars de revenu récurrent annuel dès leur première année de commercialisation, mais avec une marge brute moyenne de 25 % seulement : elles achètent leur distribution au détriment de leur rentabilité à court terme. Un modèle tenable avec des levées de fonds importantes, beaucoup moins sans.

Quand c’est un éditeur installé qui choisit la rupture, il combine les deux logiques : un compte de résultat existant qui absorbe une partie du risque, mais une rentabilité plus difficile à maintenir si la nouvelle architecture reste gourmande en coût d’inférence. Ce critère ne favorise clairement aucune des deux approches : il change la nature du risque. Essoufflement progressif d’un côté, rupture de financement plus brutale de l’autre.

8. Dette technique : un avantage réel pour la rupture, mais limité dans le temps

Approche progressive. Elle porte le poids de ses décisions passées : un code parfois ancien, des savoirs qui se perdent dans les équipes, des dépendances difficiles à faire évoluer, des choix d’architecture qui avaient du sens il y a dix ans mais freinent aujourd’hui. Chaque nouvelle fonction s’ajoute à cette base, au prix d’une complexité croissante.

Approche de rupture. Elle efface cette dette d’un coup. Elle repart sur une base plus légère, plus simple à faire évoluer dans l’immédiat, sans les compromis accumulés au fil des refontes partielles et des urgences commerciales. Cette légèreté est vraie au moment zéro. Mais une architecture agentique jeune accumule elle aussi de la dette, et le code produit avec l’aide de l’IA y contribue : une analyse de CodeRabbit portant sur 470 pull requests relève en moyenne 1,7 fois plus de problèmes sur les contributions co-écrites par IA que sur celles écrites uniquement par des humains, notamment en logique, en lisibilité et en sécurité. Un chiffre à nuancer, puisqu’une pull request co-écrite par IA couvre souvent davantage de code.

L’effacement de la dette technique est donc réel, mais temporaire. Le nettoyage promis demande la même discipline que pour l’ancien système, et la pression de livraison rapide propre aux architectures agentiques rend cette discipline encore plus difficile à tenir.

Les huit critères d’un coup d’œil

Critère	Avantage	Nuance
Donnée propriétaire et historique client	Approche progressive	La donnée brute se migre bien ; c’est la logique métier qui résiste
Conformité et responsabilité réglementaire	Approche progressive	Ne joue que pour les workflows soumis à une obligation réglementaire précise
Vitesse de déploiement et coût de développement	Approche de rupture	Livraison plus rapide, mais maintenance plus exposée aux régressions
Coût de changement pour le client	Approche progressive	Protège la base acquise, aucun effet face à un nouveau prospect
Largeur fonctionnelle ou profondeur ciblée	Aucune structurellement	Dépend de la fonction précise que le concurrent choisit d’attaquer
Ancrage dans les workflows du client	Approche de rupture	Vient de l’adaptation individuelle, reste conditionné à la fiabilité
Structure financière	Selon les circonstances	Deux natures de risque, pas de modèle clairement plus rentable
Dette technique	Approche de rupture, à court terme	Une architecture jeune réaccumule de la dette, et vite

Refonte ou évolution : la réversibilité fait la différence

Ces huit critères ne s’additionnent pas en un score final. Un éditeur peut être fort sur certains et faible sur d’autres, simultanément. La question utile n’est pas de savoir qui gagne dans l’absolu, mais sur quel terrain se joue la partie qui compte pour son produit, ses clients, son secteur.

Trois repères méritent de rester en tête au moment de l’arbitrage. Plus de 40 % des projets d’IA agentique devraient être abandonnés d’ici fin 2027, selon Gartner. La marge brute d’un produit IA tourne autour de 50 à 60 %, contre 80 à 90 % pour le SaaS classique. Et les startups IA les plus rapides financent leur croissance avec une marge brute moyenne de 25 %, un modèle réservé à celles qui lèvent beaucoup.

Un choix devra être fait, et les deux options ne se valent pas en réversibilité. L’approche progressive garde une porte ouverte : elle permet de basculer vers la rupture plus tard, workflow par workflow, à mesure que la technologie mûrit. L’approche de rupture referme cette porte dès qu’elle est engagée. Une fois l’ancien système démantelé et les équipes qui le maîtrisaient dispersées, il n’y a plus de retour en arrière crédible si le pari ne tient pas ses promesses.

Cette asymétrie mérite de peser dans la décision autant que les huit critères eux-mêmes. Mais la décision qui compte le plus n’est finalement pas celle de l’éditeur : c’est celle du client, qui tranchera critère par critère, souvent sans arbitrage global, ce qu’aucune des deux approches ne peut présumer à l’avance.