Un vendredi soir, un de mes équipiers me lâche : « On a redéveloppé un truc qui existe déjà chez trois éditeurs. » Six mois de dev. Trois personnes. Pour un module de facturation que Stripe aurait couvert en deux semaines d'intégration. Voilà le genre de décision qu'on prend sans la prendre vraiment — par habitude, par ego technique, ou parce que personne n'a posé la question au bon moment.
1.Le "build" par défaut, ce réflexe qui coûte cher
On aime construire. C'est humain, et chez les bons ingénieurs c'est presque viscéral. Le problème, c'est que le build devient souvent l'option par défaut alors qu'il devrait être l'exception justifiée.
Je vous donne un chiffre vécu : sur une plateforme interne de gestion des accès, on avait estimé le build à 4 mois. Résultat réel ? Onze mois, plus un ETP à temps plein pour la maintenance les deux années suivantes. Personne n'avait mis ce coût de run dans le business case initial. Personne ne le met jamais.
Le build a du sens quand ce que vous construisez, c'est votre différenciation. Votre moteur de scoring, votre algo métier, le truc qui fait que vos clients viennent chez vous et pas ailleurs. Là, oui. Construisez. Gardez la main.
Mais votre système d'authentification ? Votre gestion documentaire ? Votre outil de tickets internes ? Franchement. Vous n'allez pas battre Auth0, ni les 200 ingénieurs qui bossent dessus depuis dix ans.
2.Le "buy" a aussi ses factures cachées
Ne croyez pas que le SaaS vous mette à l'abri. Le buy a ses propres pièges, et ils arrivent plus tard — donc ils font plus mal.
Le premier, c'est le coût qui glisse. Vous signez à 12 000 € par an. Trois ans après, vous êtes à 80 000 € parce que vous avez ajouté des sièges, des connecteurs, un tier « Enterprise » pour avoir le SSO (ce hold-up bien connu où la sécurité de base devient une option premium). Et vous ne pouvez plus partir, parce que la moitié de vos process en dépend.
Le deuxième, c'est l'intégration. Un éditeur vous vend « prêt à l'emploi ». Dans la vraie vie, il faut brancher l'outil sur votre SI, mapper les données, gérer les cas particuliers que le commercial a balayés d'un revers de main. J'ai vu des projets « buy » où l'intégration a coûté trois fois la licence.
On a acheté pour aller vite. On a passé neuf mois à faire rentrer notre existant dans leur modèle de données. Vite, c'était relatif.— Karim B., DSI dans l'assurance
Le troisième, plus sournois : la dépendance stratégique. Le jour où l'éditeur se fait racheter, double ses prix ou ferme la ligne de produit, vous découvrez à quel point vous n'êtes pas maître chez vous.
3.La vraie question n'est pas build ou buy
La bonne question, celle que je pose systématiquement en comité désormais : est-ce que ça touche à ce qui nous rend uniques ?
Si oui → vous gardez la main, quitte à construire.
Si non → vous achetez, et vous arrêtez de vouloir tout maîtriser.
Et entre les deux, il y a une troisième voie qu'on oublie trop : le composable. Vous n'achetez pas un monolithe, vous assemblez des briques. Un service de paiement ici, un moteur de recherche managé là, votre logique métier au milieu. Vous achetez la commodité, vous construisez la valeur.
C'est là que le cloud change vraiment la donne, d'ailleurs. Pas parce qu'il héberge vos serveurs. Parce qu'il transforme des choix « tout ou rien » en choix modulaires. Un service managé de base de données, c'est du buy déguisé en build : vous gardez le contrôle du schéma, vous déléguez la sauvegarde et le patching à 3h du matin.
4.Ce que je regarde avant de trancher
Quelques garde-fous que j'utilise, et que je vous recommande de tester avant de signer quoi que ce soit — ou de lancer un dev.
- Le TCO sur 5 ans, pas le prix de lancement. Intégration, run, montée de version, formation des équipes. Le prix affiché ment presque toujours.
- La réversibilité. Si je veux partir dans deux ans, je récupère mes données comment ? Sous quel format ? À quel prix ? Si la réponse est floue, c'est un drapeau rouge.
- La compétence interne. Ai-je vraiment l'équipe pour maintenir ce que je construis ? Pas aujourd'hui — dans trois ans, quand le dev star sera parti ailleurs.
- La vélocité. Combien de mois avant que ça produise de la valeur ? Parce qu'un build parfait livré dans dix-huit mois vaut souvent moins qu'un buy imparfait branché en six semaines.
Ce dernier point, je le sous-estimais il y a encore quelques années. J'avais un biais qualité, un côté « on fait bien ou on ne fait pas ». Le terrain m'a corrigé. Le temps est une ressource, et sur certains sujets, la vitesse bat l'élégance.
5.L'erreur que je vois le plus souvent
Le build par nostalgie. Une équipe qui a construit un outil il y a six ans, qui le maintient à bout de bras, et qui refuse de le remplacer par une solution du marché parce que « c'est notre bébé ». J'ai eu ce débat une bonne dizaine de fois. C'est toujours émotionnel avant d'être rationnel.
À l'inverse — et c'est plus rare mais tout aussi coûteux — le buy par flemme. On achète pour ne pas avoir à réfléchir, on empile les SaaS, et six ans plus tard on a quarante abonnements, aucune vue d'ensemble, et une facture cloud qui donne le tournis au DAF.
Entre les deux, il n'y a pas de règle magique. Il y a une discipline : reposer la question à chaque cycle. Ce qu'on a construit hier n'est pas forcément ce qu'on doit maintenir demain. Et ce qu'on a acheté hier mérite d'être réévalué quand le contrat arrive à échéance.
Mon conseil, si vous ne devez en garder qu'un : ne laissez jamais le réflexe décider à votre place. Ni celui de l'ingénieur qui veut coder, ni celui du manager qui veut signer vite. Posez la question de la différenciation. Le reste découle de là.
