Devrais-je bâtir un outil interne ou acheter un logiciel existant?
Achetez quand le processus est courant et qu’un produit mature existe. Bâtissez quand le processus est ce qui vous distingue réellement de vos concurrents, quand aucun produit ne convient sans contournements pénibles, ou quand la tarification par utilisateur, pour une équipe qui grandit, dépasse ce que coûterait un développement ciblé.
La question à poser n’est pas « pouvons-nous le bâtir? », mais « voulons-nous en être propriétaires pour toujours? ». Chaque outil interne est un engagement d’entretien permanent : les dépendances vieillissent, la personne qui le comprenait s’en va, et l’outil devient discrètement essentiel à des processus que personne n’a documentés. Cet engagement vaut la peine pour le processus qui vous fait gagner de l’argent; c’est un mauvais échange pour une tâche courante — la comptabilité, la paie, le courriel et la prise de rendez-vous sont des problèmes résolus, et bâtir votre propre version de l’un d’eux, c’est payer pour réinventer un produit avec une fraction des tests.
Une voie mitoyenne fonctionne étonnamment souvent : acheter la plateforme, et bâtir la mince couche sur mesure qui l’adapte à vos besoins. Vous obtenez l’entretien du fournisseur et votre propre processus. La plupart des plaintes du genre « le logiciel ne nous convient pas » portent en réalité sur les derniers 15 % — l’étape d’approbation qu’il ne peut pas modéliser, le rapport qu’il ne peut pas produire, les deux systèmes avec lesquels il refuse de communiquer — et une mince couche par-dessus l’API du fournisseur règle ça sans prendre en charge tout le produit.
Surveillez le signe que la décision a déjà été prise pour vous : la couche de contournements. Quand l’équipe gère le « vrai » processus dans des tableurs exportés du produit, réimporte les corrections à la main et tient un suivi parallèle pour ce que le produit ne peut pas représenter, vous entretenez déjà un logiciel sur mesure — la pire sorte, sans droits d’accès, sans historique et sans responsable. À ce stade, le développement ne s’ajoute pas à vos coûts; il regroupe des coûts que vous payez déjà en main-d’œuvre et en erreurs.
Le côté achat du bilan mérite lui aussi un calcul honnête. La tarification par utilisateur augmente avec l’effectif pour toujours, les forfaits réservent les fonctions dont vous avez vraiment besoin au plan coûteux, et le coût de sortie grandit chaque mois à mesure que vos données et vos habitudes s’accumulent dans le produit. Comparez trois ans d’abonnement plus le temps passé aux contournements avec un développement ponctuel plus son entretien — pas un mois contre une facture.
Le calcul lui-même a changé. Le réflexe d’avant, c’était d’acheter, parce que bâtir voulait dire des trimestres de travail de développeur et une soumission à six chiffres. Avec l’IA dans le processus de livraison, un outil interne ciblé se livre en quelques jours ou semaines — environ dix fois plus vite que la norme d’avant l’IA — ce qui déplace le point de bascule vers le développement pour tout processus qui vous est vraiment propre. Le test honnête n’a pas changé : si un produit mature modélise bien votre processus, achetez-le et passez à autre chose. Ce qui a changé, c’est la fréquence à laquelle la réponse à « est-ce que quelque chose convient vraiment? » peut maintenant être, à coût raisonnable : « non, alors on a bâti exactement ce dont on avait besoin ».
Dernière révision le 28 août 2026