Développer ou acheter un logiciel d'entreprise : un cadre de décision

La mauvaise question, posée chaque année

Toute organisation finit par tenir cette réunion : faut-il développer ce système ou l'acheter ? Le débat est généralement mis en scène comme une comparaison de coûts — le devis d'un éditeur face à une estimation interne — et généralement tranché sur de mauvaises preuves. Le prix d'achat et le coût initial de développement sont les deux plus petits chiffres de l'équation. La décision qui compte porte sur la propriété : qui contrôle le rythme d'évolution d'une capacité dont votre entreprise dépend, et combien ce contrôle coûte sur une décennie.

Cet article présente la manière dont nous menons cette analyse avec les CTO : un coût total de possession calculé honnêtement, une dette d'intégration chiffrée avant la signature et un test de différenciation qui montre où l'ingénierie sur mesure est réellement rentable.

Le coût total de possession, calculé honnêtement

Chaque camp flatte ses propres chiffres. Les équipes internes estiment le développement et omettent les années de maintenance ; les éditeurs annoncent la licence de la première année et omettent tout ce qui suit. Un modèle de coût total de possession honnête chiffre le cycle de vie complet des deux côtés :

• Développer : la livraison initiale plus 15 à 20 % du coût de développement par an pour la maintenance, la mise à jour des dépendances et le travail de sécurité — pendant toute la vie du système
• Développer : l'équipe. Un système construit par une équipe projet puis laissé orphelin se dégrade plus vite que tout ce que vous auriez pu acheter
• Acheter : une tarification par utilisateur qui évolue avec vos effectifs, pas avec votre valeur — recalculez le contrat avec trois fois les licences d'aujourd'hui
• Acheter : les frais de personnalisation et de conseil, qui sur les grandes plateformes dépassent régulièrement la licence elle-même
• Dans les deux cas : le coût de sortie. Migrer hors de n'importe quel système la cinquième année est un projet que personne ne budgète la première année

Faites tourner le modèle sur sept à dix ans, pas sur trois. La plupart des systèmes achetés paraissent bon marché sur trois ans et coûteux sur dix ; pour les systèmes développés, c'est l'inverse. L'horizon que vous choisissez est la décision elle-même.

La dette d'intégration : le poste caché

Aucun système d'entreprise ne fonctionne seul. Chaque achat ajoute un nœud à votre graphe d'intégration, et c'est sur les arêtes que meurent les budgets : identité, données de référence, chaînes de reporting et synchronisations point à point qui s'accumulent autour de tout produit acheté. Les plateformes achetées s'intègrent aux conditions de l'éditeur — ses limites d'API, son rythme de mise à jour, son modèle de données. Chaque personnalisation que vous y greffez vous rapproche du pire des deux mondes : des coûts de maintenance dignes du sur-mesure avec le niveau de contrôle d'un produit acheté.

Chiffrez explicitement le travail d'intégration avant la décision, pas après. Si raccorder une plateforme achetée à votre paysage applicatif coûte plus de la moitié du développement de la capacité elle-même, l'option d'achat n'a jamais vraiment été un achat.

Le test de différenciation

Le filtre le plus puissant n'est pas financier. Demandez-vous si la capacité vous différencie sur votre marché. Les capacités banalisées — paie, gestion des tickets, e-mail, notes de frais — doivent être achetées sans cérémonie ; personne ne choisit un fournisseur pour son outil de notes de frais. Les capacités qui apparaissent dans votre argumentaire commercial, vos marges ou votre expérience client méritent une ingénierie sur mesure, car posséder leur rythme d'évolution est précisément l'enjeu.

• Achetez là où la parité suffit — paie, RH, gestion des tickets, gestion documentaire
• Développez là où réside l'avantage — moteurs de tarification, parcours orientés client, le processus que vous seul exécutez
• Interrogez la zone grise : si vous écrivez de lourdes personnalisations dans un produit acheté, le marché vous dit que cette capacité est au cœur de votre métier

Des stratégies hybrides qui tiennent

En pratique, la réponse mature est rarement pure. Les modèles hybrides que nous voyons réussir partagent une propriété : une couture nette entre ce que vous possédez et ce que vous louez.

• Achetez le moteur, développez l'expérience — un système de référence acheté derrière une interface sur mesure que vos équipes et vos clients utilisent réellement
• Développez le cœur, achetez la périphérie — une logique métier sur mesure entourée de services standard pour l'identité, la messagerie et l'analytique
• Encapsulez avant de remplacer — une couche d'API que vous possédez au-dessus d'un système hérité ou d'un système éditeur, afin de pouvoir le remplacer plus tard sans toucher à ses consommateurs

Le modèle qui échoue est la personnalisation en profondeur : modifier une plateforme éditeur si profondément que chaque mise à jour devient une migration. Il cumule le profil de coûts du développement avec les contraintes de l'achat.

Un cadre à dérouler en une seule réunion

Avant la prochaine discussion développer ou acheter, posez cinq questions sur la table :

• Cette capacité nous différencie-t-elle, ou la parité avec les autres nous suffit-elle ?
• Nos exigences évolueront-elles plus vite que la feuille de route de n'importe quel éditeur ?
• À quoi ressemble le coût total de possession honnête sur dix ans — maintenance, licences, personnalisation, intégration, sortie ?
• Pouvons-nous constituer et fidéliser une équipe pour toute la vie du système, pas seulement pour le développement ?
• Combien coûte le départ — au 36e mois, sur chacune des deux voies ?

Des réponses qui parlent de différenciation, d'évolution rapide et d'équipe durable orientent vers le développement. Parité, stabilité et intégration légère orientent vers l'achat. Tout ce qui se situe entre les deux mène à un hybride, avec une couture tracée délibérément. Les systèmes d'entreprise sont l'un des volets du travail d'ingénierie que nous menons chez Vendenis — et que l'analyse conclue au développement, ou à l'achat et à l'intégration, nous aidons les organisations à concrétiser la réponse dans les deux cas.