À partir de quel montant de licence SaaS un assureur a‑t‑il intérêt à faire développer son logiciel métier.

Bonjour, effectivement, merci beaucoup. Écoute, moi je suis un ancien dev, j'ai toujours codé depuis l'âge de 10 ans. Et puis en 2008, j'ai créé une première boîte qui s'appelait Adyax, on faisait des applications métiers avec un CMS Drupal à l'époque. On avait bossé pour la terre entière, LVMH, Saint-Gobain, World Bank, voilà. J'ai vendu ça au groupe Smile, très sympa, un intégrateur open source très connu en 2018 pour recréer code.store avec cette idée. On est parti d'une idée simple puisqu'on va refaire du service, on est une boîte de service. On fait du logiciel sur mesure, du logiciel métier sur mesure. Mais avec cette idée, c'est qu'avec les avancées récentes, le logiciel devient une commodité. Avant, ce qui était des projets longs et très coûteux, souvent dérivants sur des années et des millions. Aujourd'hui, grâce aux dernières avancées, pas que l'IA, c'est pas que ça, c'est tout le système, les frameworks, les plateformes low-code, les plateformes DevOps, cloud, permettent de développer du logiciel beaucoup plus rapidement. Et c'est sur ça qu'on a parié en créant code.store. Ça fait 6 ans qu'on existe, on est 80 et on travaille beaucoup dans l'assurance.

Alors, effectivement, pas beaucoup d'industries. Finalement, on n'a qu'une seule, l'autre verticale, c'est les médias. On travaille avec Libération, Le Point, L'Express, l'Humanité ou Record TV au Brésil, Washington Post aux États-Unis, d'ailleurs. Donc, on a des grands médias. Alors, moi, je peux faire la comparaison avec les grands médias et l'e-commerce, parce que j'avais bossé dans l'e-commerce avant. L'essentiel des différences, c'est le réglementaire. C'est-à-dire que la grosse peur ou crainte de n'importe qui est l'assureur, c'est la CPR (contrainte réglementaire), mais pas que. C'est le fait que la diversité aussi, quand on dit les assureurs, en réalité, dedans, il y a plein de métiers très différents. Quand on prend l'IARD ou l'épargne ou des choses comme ça, ce n'est pas du tout les mêmes métiers en finale. Ce n'est même rien à voir en termes de fonctionnalité, de gestion de contrat ou de sinistre. Ce n'est pas les mêmes enjeux ni les mêmes montants. Et donc, je pense que la diversité du métier de l'assurance, le fait que ce soit très réglementé et la complexité aussi, c'est-à-dire qu'une complexité multiannuelle, quand on a un contrat d'assurance vie où il y a eu des changements de réglementaire, des versements différents complémentaires sur des années et des années, parfois des dizaines d'années, ce n'est pas simple. C'est cette difficulté-là qu'on n'a pas ailleurs. Si je prends le parallèle avec les médias, le problème des médias, c'est la volumétrie, la volumétrie de contenu, c'est des millions et des millions et des millions d'articles, c'est aussi la diversité des revenus à chercher et les changements majeurs qu'ils ont côté revenus. Comment ils vendent, comment ils attirent les abonnés ? C'est très difficile. Ils font face à des concurrents géants comme Google, Meta ou TikTok. Eux, c'est la concurrence de ces grandes plateformes pour le temps du cerveau disponible qui est un enjeu majeur. Tandis que dans l'assurance, c'est cette stabilité nécessaire, cette continuité absolument nécessaire dans les systèmes informatiques.

Il y a deux aspects, enfin trois aspects. Il y a trois niveaux, trois niveaux de réponse qu'on peut avoir. Le premier, le plus évident, celui qui nous concerne le plus, c'est de dire en quoi est-ce que l'usage de l'IA et des derniers modèles nous accélèrent la modernisation. Très concrètement, on peut aujourd'hui rétro-documenter un logiciel de 2 millions de lignes de code COBOL en quelques jours. Donc, on peut retrouver de la connaissance sur les règles métiers, sur le modèle de données, sur les process très rapidement. Ce qui va permettre dans un projet de migration d'être beaucoup plus rassurant vis-à-vis des stakeholders, de la DSI, en disant, écoute, on est capable de s'engager forfaitairement à une migration sur 12 mois, 8 mois, 6 mois de ton logiciel qui a été développé en VB6, COBOL, S400, je ne sais quoi d'autre. Et on sait où on va aller, on sait qu'on arrivera au bout, on sait qu'on migrera les données, et ça va se passer pour un montant fixe et une durée fixe, ce qui n'était déjà pas le cas avant. Donc ça, l'IA, sans IA, ça n'aurait jamais été possible. Là, j'ai une application, par exemple, qu'on rétro-analyse, où il y a 4500 fichiers, il y a 5 ans de développement d'une équipe de 10 personnes. Évidemment, dedans, aucun humain ne serait capable de rétro-documenter ça, même en plusieurs mois. Donc ça, c'est quelque chose qui est activable, possible. La génération de code, on est capable aujourd'hui, si on sait exactement ce qu'on veut faire, on décrit le modèle de données, les fonctionnalités de manière précise, on est capable d'avoir une génération de code quasi à 100% avec très peu d'intervention humaine. Donc ça, c'est le premier élément. Deuxième élément qu'on voit apparaître dans les grands assureurs, là, il y a un projet concret, je ne peux pas en parler plus dans le détail, mais c'est un projet qui démarre là, maintenant, dans les semaines à venir, pour un très grand assureur sur des risques industriels, par exemple, où le risque industriel demande du traitement documentaire immense. On a analysé des documents très divers, au format très divers, ce n'est pas du tout standardisé comme l'auto, par exemple. Et donc là, c'est comment est-ce que l'IA nous permet aux actuaires de donner un pricing le plus juste et celui qui aura un loss ratio le plus avantageux. Et là, c'est l'analyse de quantité de documentaire immense, c'est des agents IA qui vont aller chercher les statuts, le passé de l'entreprise, les sites, les clients, les concurrents, les terrains, etc. Donc, l'analyse de données très volumineuse pour mieux pricer. Et enfin, il y a le troisième niveau qui est aussi activable, c'est comment est-ce que l'IA peut m'aider à vendre mes polices, d'aller chercher mes clients, que ce soit en outreach, en closing. Là, on a des plateformes comme Alvio, par exemple, qui vont pouvoir, avec des chatbots, clôturer une vente abandonnée, réactiver des prospects qu'on n'aurait pas pu activer. Et là, pareil, c'est le volume. Donc, à chaque fois, en fait, l'IA répond à un problème, si on peut résumer tous les trois cases, c'est je suis capable de traiter un volume qu'aucun humain ne peut faire, que ce soit en contact, en analyse de code, en analyse documentaire. C'est le volume où l'IA gagne tout le temps.

Déjà, rappelez peut-être le buy. C'est mode SaaS, achat d'un éditeur, même avant. SaaS, ça a démarré en 2000 avec Salesforce, mais même avant, les éditeurs en général. Un logiciel standard du marché est intéressant quand on a un problème standard à résoudre. Si je veux avoir un site e-commerce qui vend des t-shirts, je vais acheter un Shopify, je ne vais pas refabriquer tout le système e-commerce parce que j'ai besoin de juste vendre des t-shirts. Ça n'a aucun sens. Pareil sur des CRM. Si on a 10 employés et qu'on a besoin de faire un CRM pour un suivi d'opportunités, on prend HubSpot, on prend Salesforce, ça sera très bien. Donc, tous les problèmes standards résolus de manière standard par un logiciel, on reste dans le buy. Ça reste efficient. En revanche, des problèmes se posent dans deux conditions. Soit un, le problème qu'on a à résoudre n'est pas standard. Souvent, dans les assurances, ça semble standard, mais ça ne l'est pas vraiment. Les workflows, les manières de faire ne sont pas les mêmes. Deuxième cas de figure, c'est quand on a le volume, la taille de l'entreprise fait que le modèle de facturation de ces éditeurs, qui sont plus ou moins au siège, généralement, parce qu'ils veulent prendre le plus d'argent possible qui est prenable de la part de l'entreprise, ils se disent qu'une grosse boîte de 500 employés ou 1 000 employés va avoir plus de moyens et donc, pas de raison pour qu'on le... Et là, en fait, c'est là où on va intervenir sur ces deux cas de figure-là. Soit le logiciel n'est pas assez standard, il va demander, en fait, on va prendre un SaaS, mais on va tellement le tordre que, en fait, on va investir beaucoup en développement customisé au-dessus et l'intérêt de continuer à payer des licences est relativement faible. soit la taille, le nombre de sièges demandés est tel qu'on va devoir dépenser 2, 3, 4, 5, 10 millions par an pour un logiciel. Or, aujourd'hui, pour ces montants-là, on peut faire beaucoup de choses pour 10 millions d'euros avec du cloud et de l'IA et des développeurs. On peut fabriquer beaucoup. Donc, en fait, la différence, elle est là. Soit on a un comportement, un fonctionnel qui est très spécifique, soit on a un coût de run en licence beaucoup trop important par rapport à la valeur produite du logiciel. Et, en fait, la vraie difficulté, c'est de dire en fait, ce qui a changé avec l'IA, c'est que la barre de dire à partir de quel moment, à partir de combien de coûts de licence par an il devient plus rentable de fabriquer que de louer un logiciel, eh bien, il s'est vachement abaissé. Si avant, en dessous de... Il était parfaitement logique de dépenser 5 millions par an en licence et en disant de toute façon, c'est plus rentable que d'avoir son propre logiciel. Aujourd'hui, nous, on constate que sur certaines typologies de logiciels, en dessous de 2-300 000 euros de licence par an, au-dessus de 2-300 000 de licence par an, il devient plus rentable de développer que de... Parce que le TCO, le prix total, enfin, le coût total de ownership sur 5 ans, à 200 000, c'est 1 million. Et pour 1 million sur 5 ans, on peut faire des choses sur mesure.

En fait, c'est hyper simple. On a juste repensé complètement tous les aspects de fabrication de logiciel, tous les étages de la conception, du design, de comment recueillir le besoin des utilisateurs. Avant, on devait aller voir 10, 15 personnes, faire des expressions de besoin qui étaient transformées en spécifications fonctionnelles, puis transformées en spécifications techniques, puis on faisait des wireframes, on faisait du design, du développement et après, on le faisait tester. Évidemment, quand on faisait tester entre le besoin initial et la réalité de ce qu'il fabriquait, il y avait plein de retours et puis on refaisait, on refaisait, on refaisait. Et ça faisait des projets qui dérapent et qui prenaient du temps. On a refondu la manière de concevoir le logiciel. On utilise l'IA dans tous les échanges. On peut faire le recueil du besoin en masse auprès de centaines d'utilisateurs et en sortir des insights. On peut faire, on a vu, la rétro-documentation pour s'assurer qu'on n'ait pas oublié des choses et on peut faire surtout générer des prototypes. Là, maintenant, on démarre des projets. Quasiment tous les projets qu'on démarre de logiciels métiers, c'est un prototype fonctionnel qu'on met tout de suite dès le premier sprint entre les mains d'utilisateurs. Ça accélère énormément la capacité à faire des erreurs parce que tout l'enjeu d'une fabrication de logiciels, c'est à quelle fréquence et à quelle vitesse on est capable de se tromper souvent. Plus souvent, on se trompe, on montre aux utilisateurs qu'on n'a pas compris et on refait des itérations courtes, meilleur sera le logiciel à la fin et moins il coûtera. Et la deuxième étape, c'est évidemment la fabrication du logiciel lui-même. Sprint agentique, des agents IA partout, tests automatisés qui permettent de réduire énormément le temps de développement et la maintenance qui est une grosse question. Globalement, là où toujours le logiciel SaaS gagné, c'est que globalement vous payez une licence mais vous n'occupez pas de la matière en condition opérationnelle, de l'hébergement, du déploiement, des montées de version et des bugs, des fonctionnalités. Or aujourd'hui, tout ça entre le cloud, les outils de CI, CD, donc le déploiement automatique et l'IA qui permet aujourd'hui, par exemple, sur des plateformes qu'on a en prod aujourd'hui, à peu près 80% des tickets, c'est-à-dire des petits bugs ou des petits changements, 80% de ces petits changements sont faits automatiquement par l'IA. Vous ouvrez un ticket Jira, dans 80% des cas, l'IA décide de le faire elle-même, de tester, de déployer d'abord en test, en environnement de test, puis de vous faire valider et puis passer en prod. C'est-à-dire que 80% de tickets d'un logiciel complexe, des gros logiciels métiers, je ne parle pas des petits prototypes, sont gérés de manière automatisée. Et donc, du coup, les coûts de maintien en condition opérationnelle sont divisés par 10. Face à des licences de plusieurs centaines de milliers d'euros, on a l'équivalent en maintenance qui est très faible. Et pourquoi la troisième voie ? Parce qu'en fait, un peu à l'ancienne, c'était tout fabriqué en interne avec un peu à l'ancienne, avec des process à l'ancienne, même avec mettant Claude ou Codex dans les mains des développeurs, vous avez les mêmes coûts. Parce que si la manière de faire n'est pas changée, globalement, les coûts s'accumulent. Si vous faites à l'ancienne et vous achetez un logiciel SaaS, vous allez payer beaucoup en licence en étant complètement lié à l'éditeur, souvent américain. Vous n'êtes pas souverain, vous n'êtes pas chez vous. Et surtout, vous avez le même logiciel que tout le monde. Donc, votre avantage compétitif à sortir des offres plus vite, à tester des choses, il est faible. Et nous, on offre vraiment la troisième voie ou la voie intermédiaire en disant, vous avez votre propre logiciel qui vous coûte moins cher que le SaaS, mais qui vous donne toute la flexibilité d'un logiciel sur mesure où vous pouvez faire des tests, des changements. C'est votre donnée, votre donnée souveraine. Et ça, c'est un vrai avantage, je pense.

Je donne un exemple. Un grand logiciel, un grand, très grand, donc très grosse boîte, il faut 6 milliards de chiffres qui décident pour leur système d'assistance mondiale médicale voyage de passer d'une voie soit Dynamics, soit Salesforce sur du custom-made aujourd'hui. Le coût global, incluant tout, c'est-à-dire les coûts de changement interne, la migration, la conception, l'accompagnement au changement. Il y a 1500 utilisateurs internes H24, donc c'est un très gros programme qui se déroule sur 3 ans. Et malgré tout ça, c'est-à-dire avec des consultants, nous, le développement sur mesure, l'hébergement, toutes les règles de sécurité que vous pouvez imaginer, le coût total a été divisé par 4. Par 4. Le coût global pour la boîte du coût de fonctionnement de cette application qui inclut tout, les coûts humains internes, externes, hébergement, etc. Donc ça, c'est un chiffre concret. Si on prend de manière très concrète le coût de run uniquement, c'est-à-dire le coût technique, on est passé de 2 millions à 200 000, divisé par 10. Voilà le taux de gain. On peut citer un autre exemple. On a, par exemple, une application qui est en cours d'étude, une application de 4 500 fichiers, 5 ans de développement, je vous le disais au début en intro. C'est une application qu'il faut refaire complètement parce qu'elle a été abandonnée pour tout un tas de raisons. Bref, il faut refaire l'équivalent de 5 ans de développement à 10 développeurs. Eh bien, la nouvelle itération va être refait complète de A à Z en 18 mois et à 5. Voilà les gains qu'on constate aujourd'hui. C'est énorme. Mais par contre, ce qu'on voit aussi, c'est que ça demande un niveau de séniorité et de niveau d'organisation deux fois, trois fois plus élevé qu'avant. C'est-à-dire que pour que ça marche vraiment, l'IA est un multiplicateur et si vous multipliez la médiocrité, vous obtenez beaucoup plus de problèmes et on le voit des problèmes de sécurité, de vibe coding, des trucs dans tous les sens, le code spaghetti, etc. Ça, ça reste absolument vrai. Par contre, si vous prenez des gars très seniors qui connaissent, qui savent ce qu'ils font, qui sont très bien organisés en termes de process et de méthodologie de développement, dans ce cas-là, vous obtenez de la qualité. C'est un peu ça. Ça démultiplie les différences qu'on pouvait déjà avoir avant entre les bons et les mauvais.

Merci, au revoir.