Construire ou acheter : comment trancher

« On le développe ou on l’achète ? » est l’une des questions qu’une direction me pose le plus souvent, et l’une de celles qui sont le plus souvent tranchées pour de mauvaises raisons. D’un côté, l’équipe technique qui préfère construire parce que c’est son métier et qu’elle n’aime pas dépendre d’un éditeur. De l’autre, la direction qui préfère acheter parce que l’abonnement paraît moins cher qu’une équipe. Les deux réflexes sont compréhensibles. Aucun des deux n’est une méthode.

La question s’est en plus élargie. Il y a quelques années, on choisissait entre un développement sur mesure et un progiciel. Aujourd’hui, on ajoute les SaaS spécialisés, les plateformes low-code et les solutions construites autour de modèles d’IA, qui promettent toutes de livrer plus vite que le sur mesure.

Voici la façon dont je traite la décision, dans l’ordre où je la mène.

1. Poser la question au bon niveau

La première erreur est de poser la question pour un projet entier. « Construire ou acheter notre nouvel outil de gestion commerciale » n’a pas de bonne réponse, parce qu’un outil de gestion commerciale regroupe des capacités très différentes : gestion des contacts, devis, tarification, signature, relances, reporting.

Je découpe donc le besoin en capacités métier, puis je pose la question capacité par capacité. Il est fréquent que la réponse soit « acheter » pour la majorité d’entre elles et « construire » pour une ou deux seulement, celles qui font réellement la différence. La tarification d’un distributeur avec des conditions négociées client par client, par exemple, n’est pas de même nature que la gestion d’un carnet d’adresses.

Pour chaque capacité, je note trois choses : ce qu’elle fait, qui l’utilise, et ce qui se passe si elle est indisponible une journée. Cette dernière question oriente déjà une partie des critères de sécurité, de disponibilité et de réversibilité.

2. Les options réellement disponibles

Je mets toujours les options sur la table de façon explicite, parce que les débats internes opposent souvent deux options alors qu’il y en a cinq.

L’IA mérite une remarque à part. Ce n’est pas une sixième catégorie de logiciel, c’est une brique qui peut s’acheter (un SaaS qui l’intègre) ou se construire (un développement qui appelle un modèle). La question « construire ou acheter » se pose donc à nouveau à l’intérieur de cette option. Et on peut souvent demander beaucoup moins au modèle qu’on ne le croit, comme je l’ai montré dans l’expérience sur les petits modèles.

3. Critère 1 : la différenciation

La question centrale est simple : cette capacité fait‑elle partie de ce qui distingue l’entreprise de ses concurrents, ou de ce que tout le monde fait de la même manière ?

La comptabilité, la paie, la messagerie, la gestion des congés, la signature électronique sont des capacités que presque toutes les entreprises exécutent de façon similaire. Les construire revient à payer pour refaire ce qui existe, avec moins de recul que l’éditeur. À l’inverse, un moteur de tarification spécifique, un processus de production propre, une expérience client qui fait vendre sont des terrains où l’outil standard impose une façon de travailler qui n’est pas la vôtre.

Pour éviter que chacun déclare sa capacité « stratégique », je pose trois questions :

• un client choisirait‑il l’entreprise, ou la quitterait‑il, à cause de la façon dont cette capacité fonctionne ?
• le processus actuel est‑il réellement meilleur que celui que proposent les outils du marché, ou simplement différent par habitude ?
• la capacité va-t‑elle beaucoup évoluer dans les prochaines années, au rythme de l’entreprise plutôt qu’à celui d’un éditeur ?

Si les trois réponses sont non, je considère que la capacité doit être achetée, et que c’est au processus de s’adapter à l’outil, pas l’inverse.

4. Critère 2 : le coût total sur plusieurs années

La comparaison la plus courante met en face un devis de développement et un prix d’abonnement annuel. Elle est presque toujours fausse, dans les deux sens. Je compare sur un horizon de cinq ans, poste par poste.

Deux repères usuels, à prendre avec prudence. Côté construction, la maintenance et les évolutions d’un logiciel sur mesure représentent couramment chaque année une part significative de son coût initial, et ce poste est presque toujours sous-estimé dans le devis. Côté achat, le prix affiché ne couvre souvent ni l’intégration au système d’information, ni la croissance du nombre d’utilisateurs, ni les modules qu’on découvre nécessaires après quelques mois. Je demande toujours à l’éditeur ses conditions de révision tarifaire et le prix au palier d’utilisateurs suivant.

Pour les solutions d’IA, j’ajoute une ligne : le coût à l’usage, estimé sur un volume réaliste puis sur un volume multiplié, parce qu’une adoption réussie fait monter la facture.

5. Critère 3 : dépendance et réversibilité

Toute option crée une dépendance. Le sur mesure crée une dépendance aux personnes qui connaissent le code. Le SaaS et le low-code créent une dépendance à l’éditeur. Il ne s’agit pas de l’éviter, mais de savoir combien coûterait d’en sortir.

Les questions que je pose à un éditeur, et dont je veux la réponse écrite :

• dans quel format peut‑on exporter la totalité des données, pièces jointes et historique compris, et sans intervention payante ?
• que devient l’accès aux données en cas de résiliation, de défaut de paiement ou de disparition de l’éditeur, et pendant combien de temps ?
• quel préavis pour une hausse de prix ou l’arrêt d’une fonction ?
• les règles de gestion paramétrées, les automatisations et les workflows sont‑ils exportables, ou seulement les données ?

Ce dernier point est décisif pour le low-code. Les données s’exportent généralement. La logique construite dans la plateforme, elle, s’exporte rarement sous une forme réutilisable. Une application low-code qui porte des règles métier importantes est, en pratique, une application qu’il faudra réécrire pour en sortir.

Côté sur mesure, la réversibilité se vérifie autrement : code et accès au nom de l’entreprise, documentation, tests, environnement reproductible. Ce sont exactement les points qui font défaut quand le prestataire ne répond plus.

6. Critère 4 : l’intégration au système d’information

Un outil isolé est rarement un problème. Un outil qui doit lire et alimenter l’ERP, le CRM, la comptabilité et l’annuaire des utilisateurs en est un, quelle que soit l’option choisie.

Je vérifie :

• Les interfaces disponibles : une API documentée, versionnée, avec des limites de débit connues, et des événements (webhooks) pour éviter d’interroger le système en boucle.
• L’authentification : connexion à l’annuaire de l’entreprise (SSO), création et suppression automatiques des comptes, gestion des rôles. Un outil où il faut désactiver les comptes à la main est un outil où d’anciens salariés garderont un accès.
• Le référentiel : quel système fait foi pour les clients, les produits, les prix. Deux outils qui se croient chacun maîtres des mêmes données produisent des doublons et des écarts.
• Le coût des intégrations : c’est souvent là que se trouve le vrai développement d’un projet « acheté ». Il doit figurer dans la comparaison.

Une conséquence que l’on oublie : acheter un SaaS ne supprime pas le besoin de compétences de développement. Il le déplace vers les intégrations, qu’il faudra maintenir à chaque évolution de l’API de l’éditeur.

7. Critère 5 : sécurité et données

Ce critère se traite tôt, parce qu’il peut éliminer une option d’emblée. Les questions dépendent de la nature des données, mais je pars toujours de la même liste :

• où les données sont‑elles hébergées, par qui, et avec quels sous-traitants ?
• l’éditeur fournit‑il un accord de traitement des données conforme au RGPD, et la liste de ses sous-traitants ?
• quelles preuves de sécurité peut‑il produire : certifications, rapports d’audit, résultats de tests d’intrusion récents ?
• pour une solution d’IA : les données envoyées sont‑elles conservées, utilisées pour entraîner des modèles, et pendant combien de temps ?
• qui, chez l’éditeur, peut accéder aux données de l’entreprise, et ces accès sont‑ils journalisés ?

Le sur mesure n’est pas plus sûr par nature. Il est aussi sûr que l’équipe qui le construit et l’exploite. Un SaaS sérieux dispose souvent de moyens de sécurité qu’une petite application interne n’aura jamais. Inversement, un SaaS ne vous dispense pas de configurer correctement les accès, ce qui reste à votre charge.

8. Critère 6 : les compétences pour maintenir

C’est le critère que les directions regardent le moins, et celui qui explique le plus de projets en difficulté quelques années plus tard. Pour chaque option, je demande : qui maintiendra cela dans trois ans, et avec quelles compétences ?

• Sur mesure : une équipe interne ou un prestataire qui connaît le code, sur une technologie qu’on trouve encore sur le marché. Un développement dans un langage ou un framework marginal est un risque de recrutement.
• Progiciel : un intégrateur certifié, et un référent interne qui comprend le paramétrage.
• SaaS : un administrateur fonctionnel côté entreprise et quelqu’un capable de maintenir les intégrations.
• Low-code : la personne qui a construit l’application. Si c’est un collaborateur métier seul, la dépendance à cette personne est souvent plus forte que la dépendance à l’éditeur.
• IA : quelqu’un capable de mesurer la qualité des réponses dans le temps, avec un jeu de tests, et de réagir quand le modèle change de version.

Si personne ne peut être nommé, l’option n’est pas éliminée, mais le coût de cette compétence doit entrer dans le calcul du coût total.

9. La méthode de comparaison

Une fois les critères posés, je mène la décision en cinq étapes.

1. Les critères éliminatoires d’abord. Hébergement des données, conformité, intégration indispensable, export des données : une option qui échoue sur l’un d’eux sort de la comparaison, sans débat sur les fonctions.
2. Une grille pondérée ensuite. Les six critères, avec un poids décidé par la direction avant de regarder les options. Si l’on fixe les poids après, on les ajuste inconsciemment pour justifier l’option préférée.
3. Des scénarios réels, pas des démonstrations. Je demande à chaque éditeur de dérouler trois ou quatre cas concrets de l’entreprise, y compris un cas difficile, avec de vraies données anonymisées. Une démonstration commerciale montre ce que l’outil fait bien ; un scénario montre ce qu’il fait pour vous.
4. Un essai limité dans le temps. Pour l’option retenue, quelques semaines sur un périmètre réduit, avec des critères de réussite écrits à l’avance. Pour le sur mesure, l’équivalent est un premier lot livré en production.
5. Une décision écrite. Une page : le contexte, les options étudiées, les critères, le choix, les raisons, et les conditions qui feraient revoir la décision. Ce document sert à nouveau quand on la réexamine deux ans plus tard.

10. Les erreurs que je rencontre le plus souvent

• Comparer un devis à un abonnement. Sans coût total sur plusieurs années, la comparaison favorise toujours l’option dont les coûts sont les plus visibles au départ.
• Acheter puis tout personnaliser. Un progiciel ou un SaaS lourdement adapté cumule les inconvénients des deux mondes : la dépendance à l’éditeur et le coût du spécifique, avec en prime des montées de version douloureuses.
• Construire ce qui existe déjà. Refaire une gestion des utilisateurs, un moteur de notification ou un module de facturation standard, c’est mobiliser l’équipe sur ce qui ne différencie pas l’entreprise.
• Laisser le low-code porter le cœur du métier sans gouvernance. Ces plateformes sont précieuses pour des outils périphériques ; elles deviennent un risque quand une application critique repose sur une seule personne et une seule plateforme.
• Choisir l’IA avant d’avoir défini comment mesurer la qualité. Sans jeu de tests et sans seuil d’acceptation, on ne sait ni si la solution fonctionne, ni si elle se dégrade.
• Ne jamais réexaminer la décision. Un choix pertinent il y a cinq ans peut ne plus l’être : le marché a pu produire l’outil qui manquait, ou l’éditeur a pu changer de cap.

11. Combiner les deux

Dans la majorité des cas que je traite, la bonne réponse n’est pas l’une ou l’autre, mais une combinaison délibérée. Le schéma le plus solide que je connaisse est le suivant : acheter les capacités standard, construire les capacités différenciantes, et construire aussi la couche qui relie l’ensemble.

Concrètement, cela donne par exemple un CRM du marché pour les contacts et le suivi commercial, un moteur de tarification développé sur mesure, appelé par le CRM via une API, et une couche d’intégration maîtrisée par l’entreprise, qui fait circuler clients, produits et commandes entre les systèmes. Si le CRM doit un jour être remplacé, le moteur de tarification et les règles qu’il porte restent en place.

Les règles qui rendent cette combinaison durable :

• les règles métier différenciantes vivent dans le code de l’entreprise, pas dans le paramétrage d’un outil tiers ;
• chaque outil acheté est utilisé au plus près de son fonctionnement standard ;
• les échanges entre systèmes passent par des interfaces documentées, pas par des exports de fichiers manuels ;
• un référentiel est désigné pour chaque donnée importante.

C’est aussi ce type d’architecture qui résiste le mieux à un examen extérieur, qu’il s’agisse d’un audit ou d’une due diligence technique : on y voit clairement ce qui appartient à l’entreprise et ce qui est loué.

Les leçons

• Décidez par capacité, pas par projet. Un même outil peut combiner des parties à acheter et des parties à construire.
• Construisez ce qui vous différencie, achetez le reste. Et adaptez vos processus standard à l’outil plutôt que l’inverse.
• Comparez sur cinq ans, poste par poste. Mise en place, fonctionnement, maintenance, évolutions et sortie.
• Chiffrez la sortie avant l’entrée. Export des données, de la logique et des historiques, par écrit.
• L’intégration est souvent le vrai projet. Elle doit figurer dans la comparaison et avoir un responsable.
• Nommez qui maintiendra. Une option sans compétence identifiée a un coût caché.
• Fixez les poids avant de regarder les options. Puis testez sur vos propres scénarios, et écrivez la décision.