Faire ou acheter un logiciel : trancher sans parti pris

Le piège : décider par préférence

La plupart des arbitrages « Buy vs Build » se prennent mal. Pas par manque d’analyse, mais par excès de parti pris. Une DSI fière de ses équipes pousse à construire ; une direction métier pressée pousse à acheter ; un prestataire recommande ce qu’il sait livrer. Personne n’arbitre par les chiffres.

La bonne question n’est donc jamais « acheter ou construire ? ». C’est : quelle option, sur cinq à sept ans, coûte le moins et laisse le plus de marge de manœuvre ?

Trois options, jamais deux

« Faire ou acheter » est un faux dilemme. Il y a presque toujours trois options sur la table :

• Acheter un progiciel. Rapide à déployer, coût d’entrée maîtrisé, dépendance forte dans la durée.
• Construire le logiciel dont le métier a besoin. Coût d’entrée plus élevé, propriété pleine, alignement exact sur le besoin.
• Rénover l’existant. Souvent oubliée, et presque toujours la moins risquée quand un cœur applicatif tourne encore.

Un arbitrage qui ne chiffre pas la troisième option est incomplet.

Ce que coûte vraiment un progiciel

Le prix de la licence n’est qu’une part du coût. Sur cinq ans, il faut y ajouter :

• la hausse annuelle des tarifs, souvent indexée bien au-delà de l’inflation ;
• les modules complémentaires, qui deviennent nécessaires à mesure que l’usage grandit ;
• la dépendance contractuelle : feuille de route décidée ailleurs, conditions de sortie défavorables, accès limité à vos propres données ;
• les intégrations spécifiques, presque toujours sous-estimées au départ ;
• la perte de compétence interne sur le métier outillé.

Un éditeur qui détient vos données et votre feuille de route n’est plus un fournisseur. C’est un partenaire que vous ne pouvez plus quitter.

Ce que coûte vraiment construire

Construire coûte plus cher à l’entrée : c’est mécanique. Mais le coût total supporte bien la comparaison, une fois qu’on y intègre :

• la propriété pleine du code, des données et de l’hébergement ;
• l’absence de licences récurrentes ;
• l’alignement exact sur le métier, sans fonctionnalités payées et jamais utilisées ;
• la capacité à faire évoluer l’outil au rythme de l’activité, sans attendre la prochaine version d’un éditeur.

Le vrai risque de construire est ailleurs : la dérive du calendrier et du budget. C’est précisément ce qu’un engagement au résultat supprime. Ce qui sera mesuré, à quel seuil et à quelle date est écrit au contrat ; si le résultat n’est pas atteint, la part conditionnée n’est pas due.

Une méthode d’arbitrage en quatre étapes

Parce que nous savons construire comme rénover, nous n’avons aucun intérêt à pousser une option plutôt qu’une autre. L’arbitrage suit quatre étapes :

1. Cadrer le besoin — ce que fait réellement le métier, pas ce qu’un produit sait faire.
2. Évaluer les progiciels du marché — sur le fond, mais aussi sur le contrat et les conditions de sortie.
3. Chiffrer le coût total sur cinq à sept ans pour chacune des trois options : acheter, construire, rénover.
4. Recommander, par écrit, avec des arguments défendables en comité d’investissement.

La recommandation est parfois « acheter » : quand un éditeur est mûr, que le besoin est celui de tout le monde, et que la dépendance reste maîtrisable. Nous l’écrivons alors.

Quand construire s’impose

Construire devient la bonne réponse quand le besoin n’intéresse qu’un seul client — vous — et qu’aucun éditeur n’a de raison de l’écrire. Ou quand l’achat coûte trop cher en dépendance : la feuille de route vous échappe, les données aussi, et chaque évolution devient une négociation.

Ce que vous en retirez

Une décision éclairée et défendable. Un coût total transparent, pour les trois options. Et un interlocuteur qui n’a aucune raison de fausser l’arbitrage.