Planification de la succession logicielle pour les petits fournisseurs IA

Une équipe achats passera trois réunions à interroger un fournisseur IA sur la résidence des données et la politique d'entraînement. Presque aucune ne pose la question qui détermine réellement si le fournisseur existera encore l'an prochain : que devient ce logiciel si la personne qui l'a construit disparaît.

Cet écart se creuse, il ne se referme pas. Les outils IA permettent aujourd'hui à une ou deux personnes de livrer ce qui exigeait autrefois une équipe de dix. C'est une bonne nouvelle pour les acheteurs : livraison plus rapide, coût plus bas, un système construit pour leur problème exact plutôt qu'une tranche configurée de quelque chose de générique. Cela signifie aussi qu'une part croissante du logiciel B2B repose désormais sur un bus factor de un. Personne ne couvre ce risque, parce que personne ne le demande.

Le risque de concentration que personne ne couvre

Il y a dix ans, un logiciel assez solide pour porter l'activité centrale d'une entreprise nécessitait une entreprise derrière lui. Cette corrélation a disparu. Un développeur seul, avec la génération actuelle d'outils de code IA, peut aujourd'hui construire et livrer un système qu'une équipe de cinq personnes aurait mis deux trimestres à produire il y a dix ans.

C'est précisément l'argument en faveur de travailler avec de petits fournisseurs spécialisés. Ils vont plus vite, coûtent moins cher, et construisent exactement ce dont l'entreprise a besoin plutôt que le module configurable le plus proche d'une plateforme conçue pour dix mille autres clients. Pour une activité B2B de niche, cette adéquation vaut souvent plus que la sécurité d'un nom connu.

Ce que cela introduit, discrètement, c'est un risque de concentration. Si le logiciel fait tourner l'activité quotidienne d'un client et qu'une seule personne détient tout le modèle mental de son fonctionnement, cette activité a désormais une dépendance sans filet institutionnel. Pas un scénario hypothétique. Si le fournisseur devient indisponible, réticent ou insolvable, le client se retrouve avec un logiciel qui fonctionne et aucun moyen de le maintenir en état.

Les acheteurs ne posent pas la question parce que la catégorie n'a presque pas de nom. Les questionnaires de sécurité fournisseur sont un genre mature. Les questionnaires de continuité fournisseur, pour du logiciel de l'ère IA construit par de très petites équipes, n'existent quasiment pas encore.

Les grandes plateformes vendent de la continuité, pas seulement du logiciel

Salesforce, HubSpot et Microsoft gagnent rarement une comparaison fonctionnalité par fonctionnalité face à un système construit spécifiquement pour le workflow d'une entreprise. Ce qu'ils gagnent, c'est la certitude que le fournisseur répondra encore aux tickets de support dans cinq ans, parce que l'entreprise derrière le logiciel compte des milliers d'employés et un bilan.

Cette certitude n'est pas gratuite. L'acheteur la paie de trois manières : un produit calibré pour le client médian plutôt que pour son problème spécifique, du travail d'intégration pour plier un outil générique à son propre processus, et un prix qui reflète les frais commerciaux et de support d'entreprise plutôt que le coût marginal de la fonctionnalité réellement utilisée.

Un fournisseur IA boutique ou sur mesure inverse cet échange. Meilleure adéquation, livraison plus rapide, prix plus bas. Ce qui manque par défaut, c'est le filet institutionnel, parce qu'il n'y a pas d'institution derrière, juste une personne ou une petite équipe.

Formulée ainsi, la décision n'est pas "plateforme sûre contre fournisseur risqué". C'est un arbitrage entre deux types de coûts différents : payer d'avance pour une continuité dont on n'aura peut-être jamais besoin, intégrée à chaque fonctionnalité achetée, ou payer pour l'adéquation exacte et la rapidité, et acheter la continuité séparément, délibérément, dimensionnée aux besoins réels du projet.

Ce que la continuité signifie concrètement, en cinq éléments

"On va s'assurer que vous êtes couvert" n'est pas un engagement. C'est un sentiment, et les sentiments ne survivent pas à la revue de risque d'un client. La continuité, bien faite, ce sont cinq éléments précis.

La documentation technique. Architecture, étapes de déploiement, variables d'environnement, schéma de base de données, procédures de reprise, tenue à jour plutôt qu'écrite une fois au lancement puis abandonnée. Tous les autres éléments de cette liste en dépendent. Un séquestre sans documentation à jour n'est qu'un dépôt de code que personne ne peut exploiter.

Un contrat de développeur de secours. Un développeur externe validé, sous NDA, qui revoit le code périodiquement, fait idéalement un déploiement test sur un environnement de staging pour garder ses connaissances à jour, et est contractuellement disponible pour intervenir dans un délai convenu si un événement déclencheur survient. C'est l'élément qui transforme "nous avons le code" en "quelqu'un peut réellement le faire tourner".

Le séquestre logiciel. Code source, documentation et scripts de déploiement déposés auprès d'un tiers neutre, livrés au client sous des conditions déclenchantes définies telles qu'une indisponibilité prolongée ou une insolvabilité. C'est l'élément le plus formel et le plus coûteux, et celui que la plupart des acheteurs B2B supposent exister par défaut. Ce n'est généralement pas le cas, sauf si quelqu'un le demande.

L'assurance homme-clé. Une police désignant le client, ou le projet, comme bénéficiaire, versant un capital si le fondateur ou le développeur principal décède ou devient définitivement incapable de travailler. Elle ne restaure pas la continuité par elle-même. Elle finance la transition, couvrant le coût d'un développeur de remplacement ou d'une passation précipitée pendant que le contrat de développeur de secours et la documentation font le travail opérationnel.

Une clause de continuité dans le contrat. L'élément qui rend les quatre autres opposables plutôt que simplement promis. Elle précise ce qui déclenche une passation, ce à quoi le client a droit, et dans quel délai. Sans elle, tout ce qui précède n'est que bonne volonté.

Aucun de ces cinq éléments n'exige un grand fournisseur pour être mis en place. Ils exigent un fournisseur qui a décidé, avant qu'on le lui demande, que cela fait partie de ce qu'il vend en plus du logiciel.

Chaque projet n'a pas besoin du dispositif complet

L'erreur dans l'autre sens est de traiter les cinq éléments comme obligatoires pour chaque projet. Un petit tableau de bord interne qui fait gagner deux heures par semaine à quelqu'un n'a pas besoin de séquestre logiciel. Le coût dépasserait le risque couvert.

Dimensionner selon deux questions : à quel point l'activité du client dépend-elle réellement du bon fonctionnement de ce système, et à quel point une interruption serait-elle grave. Un microsite marketing ou un outil de reporting interne a besoin de documentation et d'une clause, rien de plus. Un système qui porte l'activité quotidienne d'un client, du genre à stopper un entrepôt, un traitement de sinistres ou un service client s'il tombe, justifie le contrat de développeur de secours et, au-delà d'une certaine taille de contrat ou criticité, le séquestre et l'assurance aussi.

C'est aussi là que le coût cesse d'être l'objection attendue. La documentation relève surtout de la discipline, pas du budget. Un contrat de développeur de secours coûte quelques milliers d'euros par an pour des revues trimestrielles, à peu près le même ordre de grandeur qu'un test d'intrusion annuel que la plupart des acheteurs de logiciels B2B budgétisent déjà ailleurs. Le séquestre et l'assurance homme-clé coûtent plus cher, ce qui explique justement pourquoi ils ont leur place sur les systèmes où le risque le justifie réellement, pas par défaut sur tout.

Pourquoi nous l'intégrons dès le départ, plutôt que de le rajouter après coup

Nous avons récemment écrit sur le fait de traiter la confiance IA et la souveraineté européenne comme des décisions produit plutôt que de la communication, parce que l'acheteur a changé et pose désormais des questions précises et vérifiables plutôt que d'accepter un paragraphe sur la page à propos. La continuité est la moitié opérationnelle du même changement. La souveraineté, c'est ne pas dépendre structurellement de l'endroit où tourne le modèle d'un fournisseur ou de ce qui arrive à vos données. La continuité, c'est ne pas dépendre structurellement de la présence continue du fournisseur.

Nous exploitons plusieurs systèmes clients qui entrent carrément dans la catégorie "stopperait une activité", dont une automatisation live 24/7 dont un client dépend quotidiennement. Pour des projets à ce niveau, la documentation et une clause de continuité ne sont pas quelque chose qu'un client doit négocier après la signature du contrat. Elles font partie de ce qui est cadré avant le premier sprint.

La version honnête de cet article n'est pas "embauchez une grande plateforme pour éviter ce risque". Les grandes plateformes règlent la continuité en l'intégrant au prix de tout, que le projet spécifique en ait besoin ou non, et en abandonnant l'adéquation qui justifie de construire un système sur mesure au départ. La meilleure réponse, pour un problème B2B vraiment de niche ou complexe, est de demander au petit fournisseur en face de vous quel est son plan de continuité avant de signer, pas après que quelque chose ait mal tourné.

Que faire maintenant

Si vous évaluez un fournisseur IA boutique ou sur mesure, demandez son plan de continuité avant de signer, pas après un incident. Demandez précisément : la documentation est-elle à jour, existe-t-il un développeur de secours capable d'intervenir, et que garantit réellement le contrat si le fournisseur devient indisponible.

Si vous êtes seul ou en petite équipe à construire du logiciel B2B, la version la moins chère pour commencer est une documentation tenue à jour et une clause dans votre contrat type. Ajoutez un contrat de développeur de secours dès que l'activité d'un client dépend vraiment du bon fonctionnement du système. Le reste se dimensionne à la taille de ce que vous protégez.