Construire ou acheter, et comment trancher honnêtement
La question se présente toujours comme une comparaison de coûts et ce n’en est pas une. Sur trois ans, construire revient presque toujours plus cher qu’acheter, une fois comptés la maintenance, l’astreinte, le départ de la personne qui avait tout en tête, et le temps que l’équipe n’a pas consacré à autre chose. Si le coût était le critère, la réponse serait connue d’avance et il n’y aurait pas de débat. Le vrai critère est différent : que voulez- vous posséder dans trois ans, et qu’acceptez-vous de louer. Une organisation construit lorsque la chose en question est ce qui la distingue de ses concurrents, ou lorsque rien sur le marché ne traite sa contrainte réelle. Elle achète dans tous les autres cas, c’est-à-dire la plupart du temps. Le piège n’est pas de se tromper de réponse, il est de se raconter une histoire : on construit par plaisir technique, ou par méfiance envers les fournisseurs, en habillant la décision d’arguments financiers que personne ne vérifiera dans deux ans.
Les quatre cas où la réponse est nette
Achetez quand le besoin est standard. Gestion de tickets, transcription, recherche documentaire générale, assistance à la rédaction. Des éditeurs y consacrent des équipes entières depuis des années, leurs produits sont meilleurs que ce que vous construirez, et votre singularité supposée relève presque toujours d’une convention interne qu’il est moins coûteux de changer que de coder.
Achetez quand vous n’avez pas d’équipe pour maintenir. C’est le critère qui tranche le plus de discussions. Construire sans capacité de maintenance produit un système qui fonctionne six mois puis se dégrade, et le coût de cette dégradation dépasse largement l’abonnement qu’on voulait éviter.
Construisez quand le système est ce qui vous distingue. Si le processus en question est la raison pour laquelle vos clients viennent chez vous, le confier à un fournisseur revient à louer votre avantage. C’est le seul cas où le surcoût de construction se justifie sans arithmétique.
Construisez quand aucune offre ne traite votre contrainte réelle. Contrainte de localisation des données, intégration à un système ancien qu’aucun éditeur ne connaît, volume qui rend la tarification à l’usage absurde. Vérifiez la contrainte avant de conclure : elle est souvent plus négociable qu’annoncé.
Ce que la comparaison de coûts oublie
Le devis de construction couvre la construction. Le coût réel comprend quatre postes qui n’y figurent jamais.
La maintenance, qui représente sur la durée davantage que le développement initial. Les interfaces changent, les modèles évoluent, les sources se modifient, et quelqu’un doit suivre.
L’astreinte. Un système utilisé quotidiennement tombe en panne un mardi à dix-huit heures, et une personne doit être joignable. Cette ligne n’apparaît dans aucun devis et se paie tous les mois.
Le facteur humain. Le système a été construit par quelqu’un qui le connaît entièrement. Le jour de son départ, la documentation existante sera insuffisante, parce qu’elle l’est toujours.
Et le coût d’opportunité, le plus lourd et le moins visible. Six mois d’équipe passés à construire sont six mois non passés sur ce que personne d’autre ne peut faire à votre place.
La voie intermédiaire, et sa condition
Le montage le plus fréquent en pratique consiste à acheter le socle et à construire la couche qui vous est propre : le modèle et l’hébergement viennent d’un fournisseur, l’intégration à vos systèmes et la logique métier restent chez vous.
C’est souvent la bonne réponse, à une condition qui décide de tout. Ce que vous construisez doit être la partie qui contient votre connaissance : les règles issues de votre métier, le jeu d’évaluation constitué de vos dossiers, les correspondances entre vos référentiels. Si ce que vous construisez est au contraire une reproduction de ce que le fournisseur propose déjà, vous payez deux fois la même chose.
La frontière utile se trace ainsi : tout ce qui deviendrait obsolète si vous changiez de fournisseur doit rester léger. Tout ce que vous voudriez emporter en changeant doit vous appartenir et vivre chez vous.
Se prémunir contre l’enfermement
La dépendance à un fournisseur ne se traite pas par une clause contractuelle, qui se révèle sans effet le jour où on en a besoin. Elle se traite par la possession de deux actifs.
Vos données, sous une forme exportable et régulièrement exportée, la vérification étant le point qui compte : une possibilité d’export jamais testée n’en est pas une.
Et votre jeu d’évaluation, avec vos cas et leurs étiquettes. Le code d’intégration se réécrit en quelques semaines. Deux ans de dossiers étiquetés par vos experts ne se rachètent nulle part, et c’est cet actif qui vous permet, le jour venu, de tester un autre fournisseur en une semaine plutôt que de recommencer un projet.
Un problème, trente minutes
Décrivez une tâche qui prend trop de temps aujourd’hui, exceptions comprises. Nous vous dirons si elle vaut la peine d’être construite, et nous le dirons franchement quand ce n’est pas le cas.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
