L’illusion d’un développement devenu simple
L’IA générative alimente aujourd’hui un fantasme largement répandu : une « SaaSpocalypse », où les éditeurs de logiciels seraient remplacés par des systèmes construits à la demande, rapidement et à moindre coût.
Ce raisonnement confond vitesse d’exécution et responsabilité dans la durée.
L’intelligence artificielle donne le sentiment que développer un système logiciel n’a jamais été aussi simple. En quelques secondes, elle peut écrire une fonction, générer des tests ou documenter une API. Le temps nécessaire pour produire du code diminue nettement, et le développement paraît plus accessible.
Certaines études évoquent des gains de productivité de 20 % à 40 % sur des tâches simples ou répétitives. Mais ces gains ne sont ni automatiques ni universels. Une étude publiée en 2025 par Model Evaluation & Threat Research (METR), menée auprès de développeurs expérimentés sur des bases de code complexes, a même observé un ralentissement moyen de 19 %. Un écart révélateur entre perception et réalité.
L’IA ne remet donc pas en cause la valeur des éditeurs de logiciels. En revanche, elle met sous tension les organisations qui confondent rapidité de développement et capacité industrielle à long terme.
Écrire du code plus vite ne signifie ni construire un système robuste, ni garantir sa maintenabilité sur quinze ou vingt ans. L’IA facilite la production. Elle ne prend pas en charge la maintenance dans la durée, les migrations technologiques, la gestion des incidents en production ou l’intégration continue des évolutions indispensables au maintien d’un système à l’état de l’art.
Réduire le logiciel à du code revient à ignorer l’essentiel : la valeur réside dans la capacité à faire fonctionner, sécuriser et faire évoluer un système critique dans le temps.
Ce que l’IA ne simplifie pas
Dans l’assurance IARD, le système cœur constitue un socle critique et un actif stratégique. Il doit intégrer en continu les évolutions fonctionnelles et réglementaires, garantir la sécurité et la gouvernance de données sensibles, assurer une haute disponibilité, s’interfacer avec un écosystème étendu et supporter des volumes massifs de contrats et de sinistres, tout en restant durablement aligné avec la stratégie de l’entreprise.
L’enjeu n’est donc pas de savoir si l’on peut développer plus vite, mais si l’on est capable d’assumer, pendant des décennies, les conséquences de chaque ligne de code produite.
Chaque évolution doit être maîtrisée afin de préserver la stabilité et la fiabilité globales du système d’information. Or, lorsque les arbitrages privilégient la vitesse ou la réduction des coûts à court terme, la dette technique s’accumule mécaniquement.
Imaginons un assureur qui reconstruit son système cœur en interne en s’appuyant massivement sur l’IA. Les premiers résultats sont spectaculaires : livraisons rapides, gains visibles, sentiment d’accélération.
Sans discipline industrielle exceptionnelle, l’IA n’accélère pas seulement le développement. Elle accélère surtout l’accumulation d’erreurs, de dépendances et de choix difficiles à remettre en cause.
Quelques années plus tard, les coûts explosent, les dépendances freinent l’évolution et l’organisation passe plus de temps à corriger qu’à innover. L’entreprise se retrouve alors dans une situation très proche de celle qui avait initialement justifié le redéveloppement du système cœur.
Ce n’est pas un problème de talent. C’est un problème de maîtrise de la complexité dans la durée.
Build : choisir d’assumer la complexité dans la durée
Le build reste pleinement pertinent dans deux situations : lorsque l’avantage concurrentiel repose directement sur le cœur du système, ou lorsque l’organisation dispose d’une capacité démontrée à maintenir ce type de plateforme sur le long terme.
Certaines entreprises y parviennent avec succès. Mais les conditions sont exigeantes : équipes stables, gouvernance technique rigoureuse, investissements soutenus et culture d’ingénierie capable de résister aux cycles récurrents de réduction des coûts.
Grâce à l’IA, lancer un projet interne peut sembler plus simple. Les prototypes sortent vite et le sentiment de maîtrise est fort. Mais une DSI ne développera pas structurellement plus vite qu’un éditeur de logiciels. Les éditeurs utilisent eux aussi massivement l’IA pour accélérer le développement, automatiser les tests et améliorer la maintenance.
L’IA n’instaure donc pas un avantage durable de vitesse pour le build. Elle élève le niveau de productivité de l’ensemble de l’écosystème.
Choisir le build, c’est assumer l’intégralité de la trajectoire du système : mises à jour technologiques, évolutions réglementaires, migrations, incidents majeurs et maintien de compétences rares. Autrement dit, accepter que la DSI devienne un quasi-éditeur de logiciel, avec toutes les responsabilités industrielles que cela implique, mais sans marché pour mutualiser les coûts et absorber les risques, et avec des moyens plus limités qu’un éditeur.
La question n’est pas de savoir qui développe le plus vite, mais qui est prêt à assumer cette responsabilité pendant 20 ans.
Buy : concentrer les ressources là où elles créent de la valeur
Le débat build versus buy est avant tout une décision d’allocation des ressources.
Choisir le buy consiste à s’appuyer sur un éditeur qui prend en charge, dans la durée, la maintenance, la sécurité, la conformité réglementaire, la compatibilité des versions et l’obsolescence technologique.
Le rôle de l’éditeur n’est pas d’écrire du code, mais d’assumer durablement un socle industriel maintenu à l’état de l’art.
Cette exigence est structurelle pour un éditeur de logiciels. Elle l’est beaucoup moins pour une DSI, dont la mission première est d’aligner le système d’information sur les priorités métiers et stratégiques de l’entreprise, tout en arbitrant en permanence entre investissements, contraintes budgétaires et réalités organisationnelles susceptibles de fragiliser cet effort dans la durée.
Les éditeurs mutualisent ce qui n’est pas différenciant : les invariants métier qui structurent l’assurance sans constituer un avantage concurrentiel. Cette mutualisation évite à chaque assureur de reconstruire les mêmes fondations, avec les mêmes coûts, les mêmes risques et la même complexité.
Elle permet aux équipes internes de se concentrer sur ce qui crée réellement de la valeur : innovation produit, expérience client, distribution et exploitation de la donnée.
Adopter une stratégie de buy n’exclut pas le développement spécifique. Les assureurs peuvent adapter le système à leur contexte, à leurs offres et à leurs canaux, en développant des extensions et des parcours différenciants, sans remettre en cause la stabilité du socle industriel.
Conclusion
L’IA accélère la construction des systèmes.
Elle n’allège ni leur complexité, ni leur coût, ni leur responsabilité.
Avant de choisir entre build ou buy, les organisations doivent se poser trois questions simples et concrètes :
- Sommes-nous prêts à porter ce système cœur pendant 20 ans ?
- Avons-nous la capacité industrielle, humaine et financière pour en assumer la maintenance, la sécurité et l’évolution continue ?
- Voulons-nous mobiliser nos ressources sur la gestion d’un socle technique ou sur la création de valeur métier ?
L’IA ne change pas la nature de ces arbitrages. Elle les rend simplement plus visibles et plus rapides.
Build ou buy n’est donc pas un choix technologique, mais une décision de responsabilité industrielle.
Et à l’ère de l’IA, les organisations qui feront ce choix avec discipline plutôt qu’avec enthousiasme seront celles qui préserveront durablement leur capacité d’innovation.