La semaine dernière, j’ai passé une heure au téléphone avec un assureur. Il veut refaire son site et son application mobile : déclaration de sinistre, gestion des contrats, dépôt de pièces, et passage de relais à un conseiller dès que le parcours se grippe, ce qui, en matière de sinistres, est le cas la plupart du temps. Un vrai projet, de vrais utilisateurs.
Au bout de dix minutes, il m’a demandé à voir mon logiciel.
Pas une architecture de référence, ni une étude de cas : une démonstration de produit. Il voulait des écrans, une console d’administration, des niveaux de licence et la feuille de route de l’an prochain.
Je lui ai répondu qu’il n’y en avait pas. Nous avons passé les cinquante minutes restantes à ne pas nous comprendre.
Le malentendu n’a jamais été technique. Il savait ce que fait l’IA. Il ignorait ce qu’on lui demandait de signer.
Ce qu’il pensait acheter
Il ne cherchait pas à compliquer les choses. Il faisait son travail comme son entreprise l’a toujours fait. C’est autre chose, et c’est bien plus difficile à contester.
La liste d’achats qu’il avait en tête ressemblait à ceci :
- Un logiciel pour construire le site
- Un logiciel pour gérer les contenus
- Un logiciel pour traiter les sinistres
- Un logiciel pour relier les trois
Quatre produits, sans doute trois éditeurs, et une série de feuilles de route qui appartiennent à d’autres.
C’est le modèle qu’il connaît. Surtout, sa direction des achats s’est construite autour de lui, et ce n’est pas un mardi après-midi, sur la foi d’un fournisseur qui lui assure que le monde a changé, qu’il va le remettre en cause.
En bref : deux façons d’acheter le même résultat
| Acheter une licence | Acheter un développement |
|---|---|
| Comparer des grilles de fonctionnalités | Décrire le résultat recherché |
| Un produit et une version identifiés | Rien à nommer tant que rien n’existe |
| Trois références sur le même déploiement | Personne n’exploite la même chose que vous |
| La feuille de route appartient à l’éditeur | La feuille de route vous appartient |
| Prix par licence utilisateur, par an | Prix selon le travail accompli, par exécution |
La première colonne relève de la comparaison. La seconde vous oblige à dire ce que vous voulez avant que quiconque l’ait construit. C’est un tout autre savoir-faire, et bien moins confortable.
La phrase qui a clos l’appel
Je lui ai donc fait une proposition que je croyais généreuse : envoyez-moi votre cahier des charges, même sommaire. Un document Word avec quelques puces. Une capture d’écran de l’actuelle page sinistres, barrée de flèches rouges. J’ai connu pire.
Avec cela, je reviens avec quelque chose sur quoi il peut cliquer, pas avec un diaporama.
Sa réponse ne m’a pas quitté de la semaine.
Je ne sais pas ce que je veux. Je veux que vous arriviez avec un logiciel.
Le client, au téléphone, en août 2026. Je ne le nomme pas, ni lui ni son entreprise. Cette année, j’ai entendu d’autres acheteurs prononcer des variantes très proches de cette phrase.
Le prix n’a jamais été évoqué, pas une seule fois, et j’aurais dû y voir un signe plus tôt. Le problème était ailleurs : son organisation n’a aucun moyen d’approuver une offre qui se présente sous une autre forme qu’un produit.
Un problème d’achats, pas d’IA
Presque tout ce que je lis sur la lenteur de l’IA à s’imposer dans les secteurs traditionnels accuse la technologie. Les modèles hallucinent. La conformité bloque tout. Les données sont en désordre et, il faut bien le reconnaître, elles le sont le plus souvent.
En soixante minutes, rien de tout cela n’a été abordé. Pas une fois.
Le blocage était purement commercial. Il sait acheter une licence. Pour acheter de la capacité de développement, il n’a ni processus ni vocabulaire.
Ce sont deux muscles différents de l’organisation. Acheter une licence revient à comparer des produits qui existent déjà, exercice dans lequel la plupart des entreprises sont devenues redoutables en quinze ans. Acheter un développement revient à décrire un résultat, puis à faire confiance à quelqu’un pour l’obtenir. Le second muscle s’est atrophié pendant qu’on perfectionnait le premier, et personne ne l’a remarqué : jusqu’à récemment, on n’avait aucune raison de s’en servir.
Quand on ne sait acheter qu’en comparant, le fournisseur qui refuse la comparaison passe pour un risque plutôt que pour une chance, et l’acheteur, au vu des critères sur lesquels on l’évalue, n’a pas tort de le voir ainsi.
Une prudence qui a ses raisons
Il serait commode de faire de ce client un dinosaure. Je m’en garderai, car il n’en est pas un.
Le progiciel offre des garanties qui comptent vraiment. Un tiers en assure la maintenance et corrige les failles de sécurité à deux heures du matin sans vous consulter. D’autres clients font tourner le même code, si bien que la plupart des bugs sont débusqués par quelqu’un d’autre que vous. Et en cas de pépin, il y a un contrat à invoquer, avec un nom au bas de la page.
Le développement sur mesure traîne une longue histoire d’échecs, abondamment documentée. Quiconque a passé vingt ans dans l’informatique d’entreprise a vu un système maison devenir un fardeau impossible à maintenir, au point de survivre à trois DSI. Quelqu’un a payé cette leçon, souvent de son poste, et la prudence qu’il en a héritée est la trace d’un événement bien réel, pas un trait de caractère.
La question n’est donc pas de savoir si cette prudence était fondée. Elle l’était. Reste à savoir si elle vise toujours la bonne cible.
Le coût du développement a chuté, et tout est là
Le coût du développement a chuté, et la plupart des acheteurs n’ont pas mesuré à quel point. Personne ne les a prévenus. Les éditeurs avec qui ils traitent n’ont aucune raison de le faire, et la presse spécialisée parle des modèles plutôt que de la facture.
J’ai raconté dans cette collection, dans l’article sur l’apocalypse de l’emploi, un week-end au cours duquel j’ai mis en production, seul, deux agents opérationnels qui, dix-huit mois plus tôt, auraient occupé une petite équipe pendant quelques semaines. Ce n’était pas un coup d’éclat. C’est désormais l’ordinaire du travail, et cela se vérifie dans chacune des fonctions pour lesquelles nous avons développé.
Quand développer coûte peu, acheter un produit rigide pour éviter de développer n’est plus le choix prudent. C’est seulement le choix familier.
Pour toute une catégorie d’applications, l’équation change. Pas pour toutes. Un système central de gestion des contrats n’en fait pas partie, et je ne prétendrai pas le contraire. Mais un portail sinistres se résume pour l’essentiel à de la saisie, de la capture de documents, un suivi d’état, l’application de règles, une file d’exceptions et un passage de relais, autant de briques que nous avons déjà livrées ailleurs. Il en va de même pour l’essentiel de ce que ses quatre produits devaient couvrir.
Ce qui n’a pas baissé
Avant que tout cela ne prenne des airs d’argumentaire commercial, et je l’entends bien, voici l’autre versant.
Je ne vais pas survendre ce modèle, encore moins dans l’assurance.
Les secteurs réglementés restent soumis à des contraintes qu’aucun modèle ne fait disparaître :
- Les règles de localisation et de protection des données ne s’assouplissent pas parce que le code a été livré plus vite
- La traçabilité d’une décision sur un sinistre est une obligation légale, pas une fonctionnalité
- La troisième année, il faut toujours quelqu’un pour répondre du système, quand son concepteur est passé à autre chose
- C’est l’intégration à un système de gestion des contrats vieux de trente ans qui fait réellement échouer ces projets, et le code généré ne corrige pas une interface mal conçue
La vitesse est réelle. Le travail de gouvernance, lui, n’a pas fondu pour autant. Il compte même davantage, puisque le même nombre de relecteurs voit passer chaque semaine un volume plusieurs fois supérieur. Qui prétend le contraire devant un assureur lui vend un échec livré en un temps record.
L’affaire meurt dans l’appel d’offres
Le symptôme le plus concret de tout cela, c’est la paperasse.
Pour un projet comme le sien, un appel d’offres type pose quatre questions auxquelles je ne peux pas répondre honnêtement.
Les quatre questions, et la réponse honnête à chacune
| Ce que demande l’appel d’offres | La réponse honnête |
|---|---|
| Nom et version de la plateforme | Aucun nom de plateforme à donner |
| Coût de licence par utilisateur et par an | Les licences utilisateurs sont gratuites. Les exécutions sont facturées à l’usage |
| Trois références en production, même développement | Aucun de mes développements n’est identique au vôtre |
| Feuille de route produit sur 24 mois | La feuille de route est la vôtre, pas la mienne |
La seconde colonne est la plus honnête, et elle fait très mauvaise impression. Prenez la ligne consacrée au prix. J’entends par là qu’ouvrir un compte à quarante personnes coûte autant que l’ouvrir à quatre, et que la facture suit ce que le système exécute réellement. Pour un acheteur dont tout le modèle de coûts repose sur l’effectif multiplié par un prix annuel par licence, ce n’est pas une remise : c’est une catégorie pour laquelle il n’a aucune case. Relisez le reste de la colonne avec les yeux d’un responsable des achats, et chaque réponse paraît évasive. Un processus conçu pour écarter le flou finit par écarter la meilleure offre, et l’acheteur ne le saura jamais, car le fournisseur incapable de remplir le formulaire cesse tout bonnement de répondre.
L’intelligence de l’acheteur n’est pas en cause. Le formulaire fait exactement ce pour quoi il a été conçu, et il le fait bien, sur un marché qui ne ressemble plus à celui pour lequel on l’a rédigé.
Ce que j’ai changé dans ma façon de vendre
Voilà pour le diagnostic, qui ne coûte rien. Voici maintenant ce que le changement m’a réellement coûté.
J’ai cessé d’expliquer. Avec cet acheteur, l’explication ne sert à rien. L’IA ne le déroute pas : il lit la même presse que tout le monde. Ce qui le déroute, c’est ce qu’il est censé soumettre à son propre comité d’approbation.
J’ai donc changé l’ordre des opérations :
- Je ne vante plus des capacités : j’apporte un objet concret
- Avant le deuxième rendez-vous, je construis une version sommaire de leur outil, à leur logo et avec leur véritable parcours de déclaration de sinistre
- Je la leur mets entre les mains et je les laisse cliquer
- Puis je leur demande ce qui ne va pas
Je ne m’y attendais pas, mais les reproches se révèlent être des spécifications. Un acheteur incapable de rédiger un cahier des charges sait toujours dire ce qui cloche dans ce qu’il a sous les yeux, et il le fait en détail, sans qu’on le lui demande, en quatre-vingt-dix secondes environ. Je ne connais pas de chemin plus court entre « je ne sais pas ce que je veux » et un périmètre que quelqu’un acceptera de signer.
Cela me coûte quelques jours par prospect, dont une partie perdue sur des affaires qui n’auraient jamais abouti. Je reste convaincu que cela vaut mieux que la conversation abstraite, qui coûte les mêmes quelques jours et s’achève sur un rendez-vous de suivi.
Là où je peux me tromper
Je vends ce modèle. C’est une raison de relativiser ma lecture, pas de la reprendre à son compte.
L’objection évidente : son instinct le protège de moi. Si le développement tourne mal, il n’a ni éditeur à attaquer ni autre client utilisant le même code avec qui comparer. Je lui oppose un périmètre écrit, une approbation préalable pour tout ce qui publie ou engage une dépense, et un code qui lui reste acquis à la fin. Je crois à ces réponses. Mais c’est moi qui les ai conçues, pas lui qui les a éprouvées, et à sa place, je les trouverais sans doute un peu minces.
Il existe aussi un scénario où le progiciel absorbe tout cela et où l’avantage du développement s’efface. Les grandes plateformes intègrent en ce moment même ces schémas d’agents dans leurs produits. Si elles y parviennent, il faudra admettre honnêtement qu’il avait raison d’attendre et que j’étais en avance. Cela m’est déjà arrivé. Cela se reproduira sans doute.
À faire dès lundi
Trois choses, valables de quelque côté de la table que vous soyez assis. J’applique désormais la troisième moi-même, et c’est ainsi que je sais qu’elle est plus difficile qu’il n’y paraît.
Reprenez le dernier appel d’offres logiciel que vous avez lancé et comptez les questions qui partent du principe que la réponse existe déjà sous forme de produit. Ce nombre, c’est votre filtre, et il est sans doute plus élevé que vous ne l’imaginez.
Demandez un prototype fonctionnel à un fournisseur avant de lui demander une proposition. Payez-le s’il le faut. Quelques jours de développement coûtent moins cher qu’une procédure de sélection qui retient la mauvaise solution pour dix-huit mois.
Écrivez ce que l’outil doit vraiment faire, avec vos mots, même maladroitement. Cette version maladroite vaut mieux qu’un cahier des charges léché, parce qu’elle dit franchement ce que vous ignorez encore.
Trois convictions que je maintiens
D’abord, le vocabulaire. Dans les entreprises de taille intermédiaire, ce qui freine aujourd’hui l’adoption, ce n’est pas la qualité des modèles. C’est que les acheteurs n’ont de mots que pour les licences.
Ensuite, la direction. Dès qu’une entreprise découvre qu’elle peut commander un développement pour le prix d’un renouvellement de licence, elle ne revient pas à la licence. Ce constat vient de nos propres clients, pas d’une enquête : voyez-y une tendance qui revient sans cesse sous mes yeux, pas une loi.
Enfin, le coût de l’attente. L’acheteur qui attend de pouvoir acheter tout cela sur catalogue paie les années d’attente, puis paie une seconde fois le produit quand il arrive.
Ne demandez plus de démo. Demandez un prototype.
Il voulait que j’arrive avec un logiciel. Ce que je peux apporter, c’est une fonction de son parcours sinistres, qui tourne sur ses propres données dès la première semaine, parce que c’est précisément le périmètre de la prise en main, qui se déroule de la même manière pour chaque compte. La promesse est plus modeste que celle qu’il réclamait, et bien plus facile à vérifier avant de s’engager sur quoi que ce soit.
Ouvrez un compte et lancez un module sur une marque, ou réservez une démo pour voir la plateforme tourner sur vos propres chiffres plutôt que sur un espace de démonstration.
Écrit fin août 2026, au sortir d’un appel qui s’est mal passé. J’y reviendrai dans six mois pour relever mes erreurs, comme je l’ai fait pour l’article sur l’apocalypse de l’emploi. La suite partira vers les abonnés de ma lettre d’information.
