Le conseil a demandé : construire ou acheter. Le DSI a répondu par un tableau : deux colonnes, douze lignes, un total. Les deux colonnes finissent pareil. Dans trois ans l’intelligence est louée au compteur, la tuyauterie est à vous à maintenir ou à eux à retarifer, et la seule chose qui comptait, le modèle de votre métier, est dans un format que quelqu’un d’autre contrôle.
La mauvaise question
Construire ou acheter est une question d’achat, et elle a une réponse d’achat : le moins cher sur ce cycle budgétaire. La question qui décide de la décennie est autre. Que possédez-vous à la fin ?
Les modèles convergent, et vite. Le calcul est une commodité avec un tarif public. Le talent bouge, vers celui qui construit quelque chose. Ce qui ne voyage pas, c’est le modèle déclaré de vos propres opérations : vos entités, vos règles, les dix-sept exceptions qui existent à cause d’un incident de 2011, le vocabulaire que vos gens emploient sur le terrain.[1] C’est le dernier avantage défendable, et il se capitalise, ce que presque rien d’autre ne fait dans une entreprise. Chaque exception résolue rejoint l’actif.
Une seule question à chaque option. À la fin, où vit le modèle de mon métier, qui peut le lire, et qui peut me le retirer ?
Construire : posséder la tuyauterie, louer l’intelligence
L’équipe plateforme interne construit l’orchestration, les connecteurs, les garde-fous. Deux ans plus tard, vous possédez de la tuyauterie. L’intelligence qu’elle contient est louée, au compteur, à un fournisseur qui peut changer votre modèle, vos prix, vos rate limits ou ses conditions d’utilisation du jour au lendemain, sans vous consulter.[2] Le compteur d’inférence est la rente du siècle, et un pipeline maison la paie exactement comme un pipeline acheté.[3]
Les poids ouverts ne règlent rien. Des poids entraînés ailleurs, sur des données choisies ailleurs, selon des priorités décidées ailleurs, sont un contrat de location supérieur assorti d’une licence attrayante.[4]
Le coût profond est l’endroit où finit le modèle de l’entreprise. Le métier écrit des tickets. L’équipe plateforme les encode. La fidélité se perd à chaque conversion, et la perte est invisible, puisque personne ne tient les deux bouts de la chaîne.[5] Au bout de deux ans, le modèle de vos opérations est du code que le métier ne sait pas lire et que ses auteurs sont en train de quitter.
Acheter une plateforme américaine : louer les deux
Vous louez l’intelligence et la tuyauterie, et vous configurez le modèle de votre métier à l’intérieur du système de quelqu’un d’autre. Trente ans de logiciel d’entreprise ont exigé que l’organisation s’ajuste au produit. On ne configure pas la plateforme ; la plateforme configure l’entreprise, par accumulation de petites redditions.[6]
La configuration revient à un intégrateur facturé à la journée, dont l’intérêt est que persiste l’écart qui l’emploie ; la compréhension de l’entreprise part avec lui.[7] Le modèle est public et sans détour : des pilotes et des bootcamps menés aux frais de l’éditeur, à coût nul ou faible pour le client, destinés à être convertis en contrats de plus long terme et développés compte par compte. Une affaire saine, où l’actif qui se capitalise revient à la plateforme.
À la fin, votre ontologie existe. Elle existe dans le format de l’éditeur, sous la licence de l’éditeur, lisible par les outils de l’éditeur. Ce qui ne voyage pas a été rendu transportable, pour lui.
La troisième voie
Posséder le modèle de votre métier. Le faire tourner dans votre propre infrastructure. Payer sur la valeur qu’il produit.
L’ontologie est détenue comme un actif que vous possédez et pouvez inspecter, dans les mots de vos opérateurs, et non comme des poids enfouis dans un modèle loué.[8] Elle s’installe sous vos comptes, vos clés et votre juridiction ; nous n’opérons aucun hébergement de vos données, et le système peut tourner entièrement fermé, sur un modèle que vous hébergez vous-même, un réglage que vous vérifiez depuis votre propre réseau.[8:1] Et la facture arrive après le résultat : une part de la valeur créée, payable à la production, parce que les heures, les tokens et les sièges sont trois manières de facturer l’entrée et qu’aucune n’engage le fournisseur.[9]
Trois choses que Galahad refuse, et pourquoi. Héberger vos données, parce qu’une trace qu’il faut réclamer n’est pas la vôtre. Tenir votre modèle dans un format que vous ne savez pas lire, parce que ce qui se capitalise doit se capitaliser pour vous. Facturer avant la production, parce qu’un fournisseur payé à l’entrée a déjà été payé pour votre pilote.
Ce que cela coûte
Construire coûte une équipe, pour toujours, plus le compteur. Acheter coûte une licence, un intégrateur, plus le compteur. Les deux sont payés que ça marche ou non.
La troisième voie coûte une part de ce qu’elle vaut, et rien si elle ne vaut rien. Ce n’est pas moins cher. C’est le seul prix qui place le résultat du fournisseur du même côté de la table que le vôtre.
Les questions à poser au fournisseur
Posez-les par écrit, avant la démonstration.
- Le jour où le contrat s’arrête, dans quel format sort le modèle de mon métier, et qui peut le lire ?
- Où tourne l’inférence, et qui peut la retarifer, la brider ou la couper du jour au lendemain ?
- Qui écrit les règles : mes opérateurs, ou votre intégrateur ?
- Cela peut-il tourner entièrement fermé, sur mon réseau, sur un modèle que j’héberge ?
- Que dois-je payer avant qu’il n’y ait quoi que ce soit en production ?
- Que devient ce que vous avez appris dans mes murs ?
Un fournisseur qui répond aux six vous laisse propriétaire de quelque chose. Un fournisseur qui répond par une feuille de route vous en laisse locataire.
Monarch est la troisième voie : le modèle de votre métier comme un actif que vous possédez, installé dans votre infrastructure, payé sur la valeur qu’il produit. Voyez-le sur vos données.