Pourtant, cette perception repose sur une confusion entre vitesse d’exécution et capacité à faire vivre un système dans le temps. En effet, développer plus vite ne garantit ni la robustesse, ni la maintenabilité, ni la capacité d’évolution d’un logiciel.
Dans ce contexte, une question s’impose : l’IA change-t-elle réellement les règles du « build versus buy », c’est-à-dire le choix entre développer ses logiciels en interne et s’appuyer sur des solutions existantes ; ou en révèle-t-elle simplement les exigences ?
Développer plus vite ne signifie pas construire mieux
L'apport de l'IA générative dans les activités de développement est indéniable : selon McKinsey, elle divise par deux le temps pour écrire ou documenter du code sur des tâches courantes. Mais sur les missions complexes liées à la sécurité ou à l’adaptation, les gains tombent à moins de 10%, rappelant que vitesse ne rime pas avec robustesse durable.
Un système ne se résume pas à sa phase de construction. Il doit être maintenu, corrigé, sécurisé, adapté et mis à jour pendant des années, parfois des décennies. C’est précisément dans cette durée que se joue sa valeur réelle, bien plus que dans la vitesse à laquelle il a été initialement développé.
Confondre vitesse de développement et capacité industrielle revient donc à sous-estimer la complexité structurelle du logiciel. L’IA facilite la production, mais elle ne réduit ni les responsabilités associées, ni les contraintes d’évolution. Elle peut même accélérer l’accumulation de dépendances et de dette technique lorsque les arbitrages privilégient le court terme au détriment de la cohérence globale.
Dans ce contexte, le choix entre développement interne et recours à des solutions du marché ne disparaît pas, mais devient plus exigeant. Un système conçu en interne conserve sa pertinence dans certains cas, notamment lorsqu’il agit comme un levier direct de différenciation ou lorsque l’organisation réussit à assurer sa maintenance sur le long terme. Mais ces situations restent exigeantes et reposent sur une discipline technique et organisationnelle qui tient rarement sur la durée. Par ailleurs, l’IA ne crée pas d’avantage durable pour les organisations qui choisissent de développer elles-mêmes leur système. Les éditeurs de logiciels intègrent eux aussi ces technologies dans leurs processus, ce qui tend à homogénéiser les gains de productivité. La vitesse devient progressivement un standard partagé.
Un choix d’organisation sur le long terme
Choisir de développer en interne revient à accepter d’assumer l’ensemble du cycle de vie du système, depuis ses évolutions technologiques jusqu’à la gestion des incidents, en passant par la conformité réglementaire et la montée en charge. Cela implique de porter, dans la durée, une responsabilité industrielle complète.
À l’inverse, s’appuyer sur une solution existante consiste à confier cette responsabilité à un éditeur, dont le rôle est précisément de maintenir le socle technique à l’état de l’art, d’en assurer la sécurité, la compatibilité et l’évolution continue. Ce modèle repose sur une logique de mutualisation des efforts sur les éléments qui ne créent pas de différenciation directe.
Dans le secteur de l’assurance, ces enjeux apparaissent de manière particulièrement concrète. Les systèmes cœur doivent évoluer en permanence, intégrer des contraintes réglementaires, garantir la sécurité de données sensibles et gérer des volumes importants de transactions. Dans un tel environnement, la question n’est pas de savoir si l’on peut développer plus vite, mais si l’on est capable de maintenir un système fiable et cohérent sur le long terme. L’IA peut accélérer certaines étapes, mais elle ne simplifie ni cette complexité, ni les exigences associées.
L’exemple de ce secteur vaut pour l’ensemble des organisations confrontées à des systèmes critiques. Le véritable enjeu ne réside plus dans la capacité à produire du code rapidement, mais dans la capacité à assumer les conséquences des choix techniques sur le long terme.
Le choix entre développer en interne ou s’appuyer sur un éditeur dépasse largement celui de simple décision technique, car il engage directement la capacité d’une organisation à maîtriser, dans la durée, la complexité de son système d’information.
De son côté, l’IA accélère la construction, mais ne réduit ni les exigences de maintenance, ni les contraintes d’évolution, ni la responsabilité associée aux systèmes critiques. Elle agit en réalité comme un révélateur. En réduisant les barrières à l’entrée du développement, elle rend plus visibles les écarts entre la capacité à produire rapidement et la capacité à maintenir durablement.
Dans ce contexte, les arbitrages ne peuvent plus être guidés uniquement par la vitesse ou le coût immédiat. Ils doivent être pensés à l’aune de leur soutenabilité dans le temps. C’est sur cette capacité à inscrire les choix technologiques dans une trajectoire maîtrisée que se jouera, désormais, la véritable performance des systèmes d’information.
Par Eric Brétéché, Product Marketing Manager, Guidewire
