Le conseil d’administration demande : construire ou acheter ? Le DSI répond par un tableau, deux colonnes, douze lignes, un total en bas. Les deux colonnes finissent de la même manière. Dans trois ans, l’intelligence est louée à l’usage, l’infrastructure est soit à maintenir par vous, soit à refacturer par eux, et le modèle de votre métier est dans un format que quelqu’un d’autre contrôle.
Demandez ce que vous posséderez
Construire ou acheter est une question d’achats, avec une réponse d’achats : le moins cher sur ce cycle budgétaire. La question qui compte sur dix ans est autre : que possédez-vous à la fin ?
Les modèles convergent vite. Le calcul est une commodité. Les talents circulent. Ce qui ne circule pas, c’est le modèle explicite de vos propres opérations : vos entités, vos règles, les exceptions ajoutées après d’anciens incidents, le vocabulaire réel de vos équipes.[1] C’est le dernier avantage durable, et sa valeur s’accroît : chaque exception résolue s’y ajoute.
Posez donc la même question à chaque option : où vivra le modèle de mon métier, qui pourra le lire, et qui pourra me le retirer ?
Construire : posséder l’infrastructure, louer l’intelligence
L’équipe interne construit l’orchestration, les connecteurs, les garde-fous. Au bout de deux ans, vous possédez beaucoup d’infrastructure. L’intelligence qu’elle contient est louée, à l’usage, à un fournisseur qui peut changer le modèle, le prix, les quotas ou les conditions du jour au lendemain.[2] Un pipeline maison paie cette facture d’inférence exactement comme un pipeline acheté.[3]
Les modèles à poids ouverts n’y changent rien. Des poids entraînés ailleurs, sur des données choisies ailleurs, selon des priorités fixées ailleurs, sont un meilleur contrat de location, rien de plus.[4]
Le coût le plus lourd, c’est ce que devient le modèle de votre métier. Le métier écrit des tickets, l’équipe plateforme les traduit en code, et le sens se perd à chaque étape sans que personne ne s’en aperçoive.[5] Au bout de deux ans, votre modèle opérationnel existe sous forme de code que ceux qui font le travail ne savent pas lire, écrit par des gens qui s’en vont.
Acheter une plateforme américaine : tout louer
Vous louez l’intelligence et l’infrastructure, et vous configurez le modèle de votre métier dans le système de quelqu’un d’autre. Le logiciel d’entreprise a toujours exigé que l’organisation s’adapte au produit. Avec le temps, la plateforme façonne l’entreprise plus que l’entreprise ne façonne la plateforme.[6]
La configuration est confiée à un intégrateur facturé à la journée, dont l’activité dépend de la persistance de l’écart.[7] Le modèle commercial est public : pilotes et bootcamps à coût faible ou nul pour le client, convertis en contrats longs et étendus compte par compte. C’est une bonne affaire, et l’actif qui prend de la valeur revient à la plateforme.
À la fin, votre ontologie existe, dans le format de l’éditeur, sous sa licence, lisible par ses outils.
La troisième voie
Posséder le modèle de votre métier. L’exécuter dans votre propre infrastructure. Payer la valeur qu’il produit.
Avec Monarch, l’ontologie vous appartient et vous pouvez l’inspecter, écrite dans les mots de vos équipes. Elle tourne sous vos comptes, vos clés et votre juridiction ; Galahad n’héberge aucune de vos données, et Monarch peut fonctionner entièrement isolé, sur un modèle que vous hébergez vous-même.[8] La facture arrive après le résultat : une part de la valeur créée, payable une fois en production. Les heures, les tokens et les licences se facturent tous d’avance, et aucun n’engage le fournisseur sur un résultat.[9]
Galahad refuse trois choses. Héberger vos données, parce qu’une trace d’audit qu’il faut demander ne vous appartient pas. Détenir votre modèle dans un format que vous ne savez pas lire, parce que l’actif doit prendre de la valeur pour vous. Facturer avant la production, parce qu’un fournisseur payé d’avance a déjà été payé pour votre pilote.
Ce que coûte chaque option
Construire coûte une équipe permanente, plus l’inférence. Acheter coûte une licence et un intégrateur, plus l’inférence. Les deux se paient, que le résultat soit là ou non.
La troisième voie coûte une part de la valeur produite, et rien s’il n’y en a pas. Elle aligne l’intérêt du fournisseur sur le vôtre.
Les questions à poser à un éditeur
Posez-les par écrit, avant la démonstration.
- À la fin du contrat, dans quel format le modèle de mon métier repart-il, et qui peut le lire ?
- Où tourne l’inférence, et qui peut en changer le prix, la limiter ou la couper ?
- Qui écrit les règles : mes équipes, ou votre intégrateur ?
- Cela peut-il fonctionner entièrement isolé, sur mon réseau, avec un modèle que j’héberge ?
- Que dois-je payer avant que quoi que ce soit ne soit en production ?
- Que devient ce que vous apprenez au sein de mon organisation ?
Un éditeur qui répond aux six questions vous laisse propriétaire de quelque chose.
Monarch est la troisième voie : le modèle de votre métier comme un actif qui vous appartient, installé dans votre infrastructure, payé sur la valeur qu’il produit. Voyez-le sur vos données.