Par Dan Woods, fondateur et CEO de Socotra
Je suis ingénieur.
L’ingénierie a été ma formation, mon premier emploi et mon passe-temps favori bien avant de devenir ma carrière. J’ai passé ma vie professionnelle à construire des logiciels d’entreprise, en commençant par des contributions importantes à la base de code de Palantir 1.0 en 2006.
Aujourd’hui, l’IA peut écrire du code. Des personnes qui ne sont jamais allées au-delà du « Hello World » créent désormais des milliers d’applications simplement en décrivant leurs idées.
Deux choses sont indéniables :
- Le code généré par l’IA a libéré un potentiel immense de productivité et de valeur.
- La perspective d’utiliser du code généré par l’IA en production est terrifiante !
Socotra a suivi ces évolutions de près. Nous avons utilisé du code généré par l’IA pour améliorer notre produit et accélérer les déploiements chez nos clients, tout cela sans sacrifier la qualité ni la fiabilité. Je souhaite partager nos enseignements et nos bonnes pratiques avec les développeurs du secteur de l’assurance, dans l’espoir que des gains de productivité sûrs puissent aider l’industrie à progresser.
Pourquoi le code généré par l’IA suscite de l’anxiété chez les assureurs
Le code généré par l’IA offre un potentiel clair de gain de productivité, mais seulement si les assureurs parviennent à résoudre deux obstacles :
Obstacle n°1 : le code généré par l’IA doit être suffisamment sûr pour être utilisé en production.
Obstacle n°2 : le code généré par l’IA doit fonctionner avec les systèmes existants.
Sans résoudre ces deux points, le code généré par l’IA restera limité au prototypage autonome, ce qui a malgré tout de la valeur. Chez Socotra, nous utilisons depuis longtemps l’IA pour imaginer de nouveaux portails, des configurations de produits et des workflows. Le prototypage assisté par l’IA est rapide (et franchement amusant), mais il représente encore moins de 3 % du travail de développement que nous réalisons réellement.
La véritable opportunité apparaît lorsque l’on dépasse ces deux obstacles. Avec le temps, nous avons développé des méthodes concrètes pour rendre le code généré par l’IA prêt pour la production. Nous avons constaté que l’IA permet de développer environ deux fois plus vite en mobilisant moitié moins de ressources d’ingénierie, soit une réduction des coûts de 75 %.
On nous demande souvent comment nous faisons cela, et je vais l’expliquer ici.
Envie d’essayer le « vibe coding » en une heure ?
Il est très facile de commencer. Des outils comme Claude Code, Cursor, et GitHub Copilot permettent de générer un logiciel fonctionnel en quelques minutes. Vous pouvez esquisser des idées, explorer des workflows et tester des concepts qui auraient pris plusieurs jours ou semaines à des ingénieurs expérimentés.
Je pense que tout le monde devrait essayer au moins une fois. Voici quelques exemples que des membres non techniques de mon équipe ont réalisés grâce à des tutoriels en ligne :
- une application de liste de tâches
- une application de gestion de budget
- une page web pour un club de course à pied
Attention : cela peut devenir étonnamment addictif, surtout pour ceux qui n’ont jamais connu le plaisir de programmer.
Résoudre l’obstacle n°1:
Rendre le code généré par l’IA sûr pour la production
Un LLM peut rédiger un rapport de recherche en quelques secondes, mais je ne le publierais jamais tel quel. Le code ne fait pas exception.
Le code généré par l’IA doit être traité comme celui écrit par un ingénieur très junior. Il ne doit jamais être envoyé directement en production. À vrai dire, aucun code, qu’il soit écrit par un humain ou par une IA, ne devrait être envoyé directement en production !
Voici quelques bonnes pratiques pour le rendre sûr.
Bonnes pratiques pour rendre le code généré par l’IA prêt pour la production :
Revue de code par des ingénieurs
Des ingénieurs expérimentés doivent relire le code généré par l’IA, exactement comme ils reliraient le code d’un ingénieur junior avant de l’envoyer en production.
Tests unitaires
Les tests unitaires sont très utiles, mais il est dangereux de laisser l’IA les générer elle-même. Si l’IA comprend mal vos exigences et introduit un bug, elle risque également de mal comprendre les exigences du test. L’IA écrira alors probablement des tests unitaires qui ne réussissent que si le bug est présent !
Tests d’intégration
Les tests d’intégration valident les contrats entre les différents composants. La plupart des défaillances en production se produisent à ce niveau, et non à l’intérieur de fonctions isolées. L’IA a tendance à modéliser ces interactions complexes de manière trop simplifiée : elle simule excessivement les dépendances, ne teste que les cas favorables et ignore les véritables scénarios d’échec. Les tests d’intégration nécessitent un jugement sur la manière dont les systèmes sont censés collaborer. L’IA peut générer des tests d’intégration, mais ils doivent être examinés attentivement et tout scénario manquant doit être écrit manuellement.
Tests de bout en bout
Voici une bonne nouvelle : c’est un domaine où l’IA fonctionne très bien ! Utilisez l’IA pour définir des tests portant sur des workflows complets du point de vue de l’utilisateur. Ces tests ne réussiront que si l’ensemble du système fonctionne correctement.
Analyse statique et dynamique du code
C’est un point simple. Tous les outils qui évaluent la qualité du code des ingénieurs peuvent également analyser le code généré par l’IA. Il existe de nombreux outils populaires tels que SonarQube, CodeQL, OWASP ZAP. Choisissez-en quelques-uns efficaces et utilisez-les.
Choix de l’outil de génération de code
Le meilleur outil d’IA est une question d’opinion, et il changera probablement plus vite que votre navigateur ne peut actualiser cet article ! À l’heure actuelle, les outils populaires incluent Codex de ChatGPT, ClaudeCode d’Anthropic, et Cursor. Restez attentif aux évolutions et soyez prêt à changer lorsqu’une meilleure solution apparaîtra. Et surtout, utilisez uniquement des outils approuvés par votre équipe de sécurité.
Collaboration avec l’équipe sécurité
Chaque assureur dispose d’une équipe de sécurité. Socotra dispose également d’une équipe de sécurité complète pour protéger nos clients et maintenir notre certification ISO 27001. Nous recommandons à tous les développeurs de travailler étroitement avec leurs équipes de sécurité afin de suivre l’évolution rapide des capacités et des vulnérabilités de l’IA.
Résoudre l’obstacle n°2 : Intégrer le code généré par l’IA avec les autres systèmes
Nous avons maintenant vu les bonnes pratiques permettant d’obtenir un code généré par l’IA à la fois rapide à produire et prêt pour la production. C’est très bien si c’est tout ce dont vous avez besoin. Mais dans l’entreprise, le code ne fonctionne jamais de manière isolée. La plupart des logiciels d’assurance, et en particulier les systèmes cœur, n’ont pas été conçus en tenant compte de l’IA, ce qui peut fortement réduire les bénéfices de l’IA pour les entreprises.
Voici les caractéristiques qui rendent un logiciel compatible avec le code généré par l’IA. Elles devraient faire partie des critères essentiels lors du choix d’un fournisseur de logiciels d’entreprise. Étant donné que Socotra a été conçu en pensant à l’IA, il n’est pas surprenant que la plateforme ait été développée selon l’ensemble de ces principes.
Choisir des logiciels d’entreprise compatibles avec l’IA
Rappelez-vous ce que j’ai dit plus tôt : le code généré par l’IA doit être traité comme le code écrit par un ingénieur très junior. Si vous donniez à un ingénieur junior les clés de l’ensemble de votre base de code, vous pourriez vous attendre à une quantité ingérable de revues de code avant de pouvoir mettre quoi que ce soit en production. Les ingénieurs juniors ont besoin de garde-fous, l’IA aussi.
C’est pourquoi la modularité est essentielle, avec des interfaces clairement définies. Si l’architecture est divisée en plugins, configurations et intégrations bien délimités, et si tous les points de connexion utilisent des standards ouverts correctement documentés, alors il devient possible de confier à l’IA de petits composants à développer, puis de les tester et de les examiner raisonnablement.
Parce que Socotra est hautement modulaire, nous pouvons exploiter efficacement l’IA. Par exemple, l’IA peut modifier les règles de souscription d’un produit d’assurance ou le calcul de facturation. Dans chaque cas, le code peut être testé et déployé efficacement, sans risque de perturber d’autres parties du système.
Rechercher des langages et formats ouverts
Les IA capables de générer du code ont été entraînées sur l’ensemble des langages et formats de programmation largement utilisés. Elles connaissent Java, Python et JavaScript. Elles connaissent également JSON, CSV et les API REST.
Malheureusement pour les assureurs, de nombreuses plateformes cœur d’assurance ont inventé leurs propres langages ou formats propriétaires, sur lesquels aucun LLM n’a été entraîné. Dans ces environnements, il devient très difficile d’utiliser du code généré par l’IA.
Socotra a toujours tenu compte de cette réalité et n’a utilisé que des langages et formats largement adoptés, comme JSON et CSV pour la configuration, et Java pour les plugins.
Rechercher une documentation solide
Qu’il s’agisse d’API, de syntaxe de configuration ou d’architecture système, les ingénieurs détestent devoir demander à un fournisseur des informations qui devraient être disponibles dans la documentation. Les humains ont la possibilité d’appeler le support ou d’envoyer un email à d’autres ingénieurs. L’IA, elle, reste bloquée.
Les assureurs doivent aujourd’hui examiner la documentation de leurs fournisseurs avec un regard particulièrement critique. Dans le passé, une documentation insuffisante pouvait être compensée par plusieurs semaines de formation et un accès permanent à des experts. Ce modèle était déjà pénible pour les développeurs humains ; il devient totalement incompatible avec le code généré par l’IA.
Chez Socotra, la documentation est un pilier fondamental de nos valeurs d’ingénierie et l’a toujours été. L’IA peut rapidement et facilement exploiter cette documentation pour construire des intégrations, configurer de nouveaux produits d’assurance, développer des portails clients, et bien plus encore.
Rechercher des systèmes orientés données
De la génération de rapports à la business intelligence en passant par les intégrations avec les data lakes, de nombreux cas d’usage du code généré par l’IA reposent sur les données. Les logiciels générés par l’IA ne seront pas meilleurs dans leur utilisation des données que les logiciels d’entreprise sur lesquels ils s’appuient.
Un logiciel d’entreprise réellement orienté données doit offrir :
- des API solides permettant d’accéder aux enregistrements individuels
- un data lake intégré pour les requêtes massives
- des webhooks et des exports delta pour maintenir les systèmes externes à jour en temps réel
- des réponses serveur rapides pour toutes les opérations d’accès aux données
- un haut niveau de disponibilité afin que les données soient toujours accessibles
- une cohérence des données en temps réel dans l’ensemble du système
Si votre plateforme d’entreprise ne dispose pas d’API robustes, votre IA aura du mal à écrire du code pour interagir avec elle. Si elle ne permet pas de requêtes massives, l’IA ne pourra pas générer de rapports. Si le système est lent, le code généré par l’IA sera lent lui aussi. Et si le système subit des interruptions fréquentes… vous voyez l’idée.
Si les flux de données au sein de votre entreprise sont trop complexes et trop asynchrones au point que vos propres ingénieurs ont du mal à ajouter de nouvelles fonctionnalités, alors le code généré par l’IA aura les mêmes difficultés.
Le Model Context Protocol (MCP) est actuellement le standard le plus populaire pour connecter l’IA aux autres plateformes logicielles. Une plateforme logicielle moderne dispose d’interfaces utilisateur pour l’interaction humaine, d’API pour l’interaction avec d’autres logiciels, et de serveurs MCP pour l’interaction avec l’IA.
Cela sort quelque peu du sujet lorsque l’on évalue la capacité d’un logiciel d’entreprise à bien fonctionner avec du code généré par l’IA, mais c’est néanmoins indispensable pour qu’une plateforme puisse être considérée comme compatible avec l’IA. Grâce à un serveur MCP, les LLM les plus récents n’ont besoin d’aucun code pour se connecter aux plateformes d’entreprise. C’est la raison pour laquelle le MCP est pris en charge par de grands éditeurs de logiciels d’entreprise tels que Salesforce, Snowflake, Atlassian, Hubspot, et (bien sûr) Socotra.
Le serveur MCP de Socotra est entièrement documenté, avec des instructions permettant de le connecter à Claude ou Cursor en seulement dix minutes.
En résumé :
Les gains de productivité
Voici les gains de productivité réels que les ingénieurs de Socotra constatent en moyenne pour ces différentes tâches d’ingénierie. Pour les raisons décrites dans la section « Résoudre l’obstacle n°2 » ci-dessus, presque aucun de ces gains de productivité n’est possible avec d’autres plateformes cœur d’assurance, car elles n’ont pas été conçues pour fonctionner avec l’IA.
Ces gains de productivité concernent les développeurs, qui peuvent mettre en œuvre ces cas d’usage avec ou sans IA. Pour les utilisateurs non techniques, les gains sont potentiellement infinis puisqu’ils ne disposaient auparavant d’aucun moyen de générer du code. Cependant, le code généré par une personne qui ne sait pas comment le relire ou le vérifier peut être très dangereux en production. Dans certains cas, avec les bons garde-fous, cela peut être envisageable, mais ce sera peut-être le sujet d’un prochain article de blog.
Par ailleurs, lorsque le logiciel contient une logique métier dense avec de nombreux cas particuliers, l’IA peut générer très rapidement du code à partir d’exigences exprimées en langage naturel. Mais la charge de tests augmente alors rapidement. Une logique d’IA qui s’auto-teste réussira toujours. Utiliser une autre IA pour tester aide un peu, mais les tests destinés à la production doivent être examinés attentivement par un ingénieur expérimenté. C’est pourquoi les gains de productivité sont très différents entre le prototypage et la production pour des éléments tels que les algorithmes de tarification ou les règles de souscription. De plus, lorsqu’une logique est complexe, la finalisation des exigences prend souvent plus de temps que l’implémentation elle-même, que l’IA soit utilisée ou non.
Et maintenant ?
Il existe une puissance claire et considérable dans l’utilisation de l’IA pour générer du code et d’autres actifs numériques, mais aussi des risques évidents. J’ai décrit ici les bonnes pratiques que nous appliquons pour maximiser les gains de productivité sans compromettre la qualité ni la sécurité.
Comme les capacités de l’IA évoluent très rapidement, je conclurai par quelques prévisions concernant l’avenir du développement assisté par l’IA :
Améliorations attendues du développement assisté par l’IA
Aujourd’hui, l’IA est capable d’apporter de petites modifications isolées, même dans des bases de code relativement importantes. Au cours des prochaines années, l’IA sera capable de gérer des changements de plus en plus complexes, allant jusqu’à implémenter des fonctionnalités complètes de complexité moyenne. Elle deviendra également plus performante pour expliquer aux ingénieurs humains les abstractions et les modifications de modèles de données, ainsi que leurs avantages et leurs compromis.
Parallèlement, les coûts de changement entre plateformes logicielles d’entreprise vont fortement diminuer. Le coût de migration vers Socotra a déjà diminué de 50 % grâce à l’IA. Les coûts de changement continueront de baisser pour les plateformes compatibles avec l’IA (voir « Résoudre l’obstacle n°2 » ci-dessus).
Enfin, des situations apparaîtront bientôt dans lesquelles des utilisateurs métier réellement non techniques pourront modifier du code en production en toute sécurité. Cela est même déjà possible aujourd’hui dans certains cas très spécifiques, avec les bons garde-fous.
Limites qui devraient persister avec le développement assisté par l’IA
Les ingénieurs humains rencontrent des difficultés lorsqu’ils travaillent sur des bases de code anciennes qui manquent de modularité, de cohérence et de documentation. L’IA rencontrera les mêmes difficultés. La seule différence est que l’IA fera des erreurs ou abandonnera plus rapidement. De plus, simplement traduire un code d’un ancien langage vers un nouveau n’améliore pas sa maintenabilité.
Ensuite, il faudra très longtemps avant que l’IA puisse concevoir l’architecture de systèmes complexes. Concevoir un système complexe est un exercice stratégique qui implique de nombreuses considérations, notamment :
- Comment les besoins métier pourraient évoluer à l’avenir ?
- Comment l’organisation est-elle structurée ?
- Quelles décisions la direction est-elle susceptible de prendre dans le futur ?
- Quelles nouvelles technologies seront disponibles ?
- Quelles technologies actuelles seront évitées ou abandonnées ?
- Quelles informations métier pourraient être demandées demain alors qu’elles ne sont pas utilisées aujourd’hui ?
- Quelle est la valeur relative de chaque fonctionnalité, et pourquoi ?
Lorsque l’IA sera capable de répondre à ce type de questions stratégiques mieux que les humains, nous vivrons probablement dans un monde d’entreprises dirigées par l’IA, et moi je vivrai probablement dans un monde où je chercherai un nouveau travail. Cela arrivera peut-être un jour, mais pas tout de suite.
Enfin, il faudra aussi beaucoup de temps avant que l’IA inspire davantage confiance que les ingénieurs humains. Qu’il s’agisse de limitations réelles de l’IA ou de biais humains irrationnels, le résultat reste le même : un dirigeant attendra toujours qu’un autre humain lui confirme que le code a été examiné et testé. Tant que les humains ne changent pas, l’IA restera un simple outil. La technologie évolue rapidement, mais les humains beaucoup moins.
Conclusion
Le développement assisté par l’IA est déjà là, et il est trop puissant pour que les assureurs puissent l’ignorer. Comme tout outil puissant, il peut être extrêmement utile ou extrêmement dangereux. Aujourd’hui, les assureurs peuvent réduire leurs coûts de développement de 75 % et doubler leur vitesse IT s’ils appliquent les bonnes pratiques et travaillent avec des plateformes compatibles avec l’IA.
Je suis toujours intéressé par des échanges avec des assureurs qui cherchent à adopter des technologies compatibles avec l’IA et à exploiter de manière sûre la puissance du développement assisté par l’IA. À mesure que l’IA continue d’évoluer rapidement, les choix de plateformes faits aujourd’hui peuvent se transformer en avantages considérables demain.
À propos de Dan Woods
Dan Woods est le fondateur et CEO de Socotra, la plateforme cœur d’assurance native pour l’IA. Il est titulaire d’un master en informatique de l’université de Stanford, où il s’est spécialisé en intelligence artificielle et a publié des travaux de recherche en IA largement cités. Dan a été le troisième ingénieur backend chez Palantir, où il a développé les premières fonctionnalités d’intelligence artificielle de la plateforme. Il a ensuite dirigé les partenariats de Palantir et piloté plusieurs déploiements majeurs. Par la suite, il a fondé Socotra afin d’apporter au secteur de l’assurance des technologies avancées mais éprouvées.
Le fil conducteur de la carrière de Dan est l’intersection entre l’intelligence artificielle et les plateformes d’entreprise à grande échelle. Socotra a ainsi été conçu avec une capacité exceptionnelle à évoluer à grande échelle et à prendre en charge l’IA en production.