Le dossier est solide. Deux colonnes, un horizon de cinq ans, des hypothèses assumées : d’un côté l’acquisition d’un progiciel du marché, licences et projet d’intégration ; de l’autre un développement sur mesure, charges internes et prestations. Le progiciel l’emporte, avec une marge confortable, et il l’emporte accompagné d’un argument que personne ne conteste en comité : on ne développe pas ce qui existe déjà.

Trois ans plus tard, la même organisation vit avec un système que ses équipes appellent « notre » application. Le socle est bien celui de l’éditeur, mais il porte une longue liste d’adaptations, ajoutées une par une, chacune parfaitement justifiée au moment où elle a été demandée. La montée de version est devenue un projet à part entière, dont le chiffrage surprend tout le monde. Le support de l’éditeur s’exerce désormais sous réserve. L’entreprise paie le prix du standard et supporte les contraintes du sur-mesure.

Le cas symétrique est tout aussi banal, et moins commenté : une organisation qui a développé, avec talent, un système pour une fonction que rien ne distingue de celle de ses voisines — et qui découvre, quelques années plus tard, qu’elle doit maintenir en propre un domaine où elle n’a jamais voulu être différente, en s’en remettant aux deux ou trois personnes qui savent encore comment il fonctionne.

Ces deux histoires n’ont pas pour cause une erreur de calcul. Elles ont pour cause une erreur de question. L’arbitrage entre standard et spécifique est presque toujours instruit comme une comparaison économique, alors qu’il tranche deux choses bien plus structurantes : où l’organisation accepte de fonctionner comme tout le monde, et ce qu’elle garde le droit de changer sans en demander la permission. Le coût est la conséquence de ces deux décisions. Il n’en est pas le critère.

Une comparaison qui ne compare pas la même chose

La comparaison chiffrée n’est pas inutile. Elle est simplement biaisée d’une manière que la présentation en deux colonnes rend invisible.

Elle oppose d’abord un prix à une estimation. D’un côté, des licences négociées et un projet d’intégration engagé par un fournisseur qui s’avance ; de l’autre, une charge évaluée en interne, généralement par ceux-là mêmes qui souhaitent construire. Les deux nombres ont la même apparence et pas du tout le même statut. La décision récompense alors l’option qui sait se chiffrer, pas nécessairement celle qui sert le mieux l’organisation.

Elle place ensuite sur la même ligne deux futurs qui n’ont rien de commun. Le prix du progiciel contient l’entretien permanent assuré par l’éditeur — corrections, évolutions réglementaires, adaptation aux socles techniques — mais il ne contient ni les adaptations qu’on lui demandera, ni les montées de version qui les rattraperont. Le chiffrage du développement ne contient rien de tout cela mais engage, lui, une équipe pour aussi longtemps que le système vivra. Les deux colonnes n’omettent pas les mêmes choses, et elles ne les omettent pas dans le même sens.

Surtout, les deux options n’achètent pas le même bien. L’une achète un mode de fonctionnement déjà constitué, éprouvé ailleurs, avec ses partis pris. L’autre achète la liberté d’en définir un. Les comparer par le prix revient à comparer un abonnement et une construction : l’exercice a une réponse, mais elle ne dit pas grand-chose de ce qu’on cherchait à savoir. À coût égal — et c’est le point — les deux options laissent l’organisation dans des situations radicalement différentes quant à ce qu’elle pourra changer ensuite.

La question qui tranche : où voulez-vous être différent ?

L’erreur de méthode la plus fréquente consiste à ouvrir le marché avant d’avoir cadré le besoin. Dès qu’une démonstration a eu lieu, le besoin se décrit dans le vocabulaire du produit, et l’arbitrage est joué avant d’avoir été instruit. La décision se prend en amont, à partir des capacités métier — de ce que l’organisation doit savoir faire — et non à partir d’une liste de produits.

Pour chaque capacité, trois questions suffisent à orienter le choix.

Cette capacité différencie-t-elle réellement ? La mauvaise formulation est « notre processus est-il particulier ? » : tout processus est particulier, et chaque métier saura le démontrer. La bonne formulation est plus exigeante : perdrions-nous quelque chose si nous faisions exactement comme un concurrent ? Et, complémentaire : cette particularité vient-elle d’un choix délibéré, ou de l’histoire ? La spécificité revendiquée est le plus souvent une sédimentation — la trace d’une contrainte disparue, d’un outil qu’on n’utilise plus, d’un arbitrage dont personne ne se rappelle la raison. Une capacité réellement différenciante est rare, et elle a un propriétaire capable d’expliquer en quoi la différence produit de la valeur. Tout le reste — la comptabilité générale, la paie, les achats indirects, la gestion documentaire — doit être conforme, pas original.

L’offre du marché est-elle mature sur ce domaine ? Dans un domaine bien normalisé, un progiciel encapsule des années de pratique accumulée chez des dizaines d’organisations : construire revient à réapprendre cela à ses frais, y compris les cas particuliers qu’on n’a pas encore rencontrés. Dans un domaine émergent, ou très local, il n’y a souvent rien à acheter qui corresponde vraiment — et le « standard » proposé n’est alors qu’un développement spécifique fait ailleurs, vendu au prix d’un produit.

Qui absorbe les changements imposés ? Une capacité soumise à une pression réglementaire forte plaide pour le standard — à condition que l’éditeur entretienne réellement cette conformité pour le marché concerné. La précision n’est pas rhétorique : un produit international n’est pas nécessairement maintenu au rythme des obligations locales, déclaratives, sociales ou fiscales. Lorsque cette couverture est déléguée à un module de localisation ou à un partenaire tiers, le risque de conformité revient de fait à l’organisation, tandis que les contraintes du progiciel, elles, restent entières. C’est une question à instruire explicitement pendant la sélection, pas une propriété qu’on peut supposer.

Le choix n’est pas binaire

Entre le service standard consommé tel quel et le développement intégral, il existe un continuum : le progiciel paramétré dans son périmètre prévu, le progiciel étendu au moyen d’un modèle d’extension documenté, l’assemblage de composants techniques autour d’un noyau du marché. Se situer sur ce continuum est utile, mais ce n’est pas la décision la plus importante.

La décision la plus importante consiste à ne pas trancher pour un domaine entier. Une capacité se décompose, et ses sous-capacités n’ont presque jamais le même profil. Dans la plupart des domaines, l’essentiel est commun et une frange étroite est différenciante. Acheter le socle commun et ne construire que la frange, autour et non dedans, reliée par des interfaces explicites, est souvent la bonne réponse — à deux conditions : que la frontière soit tracée délibérément, et que ce qui est construit reste à l’extérieur du produit plutôt qu’inséré dans son cœur.

Cette décomposition n’est possible que si le produit standard accepte d’être un composant : exposer ses données, ses événements et ses fonctions à des systèmes qu’il ne connaît pas. Un produit qu’on ne peut étendre que de l’intérieur interdit ce découpage et pousse mécaniquement vers la dérive décrite ci-dessous. C’est un critère de sélection, et il pèse plus lourd qu’une bonne part de la grille fonctionnelle.

Le paramétrage qui devient du spécifique

C’est ici que se joue l’essentiel, et le mécanisme mérite d’être décrit précisément, parce qu’il n’est jamais le produit d’une décision unique.

Ce qu’on appelle globalement « paramétrage » recouvre en réalité quatre niveaux d’écart au standard. Le premier est la configuration dans l’espace prévu par l’éditeur : options, règles, champs, circuits de validation anticipés. Elle est portée par le produit et survit aux montées de version. Le deuxième est l’extension par un modèle documenté et supporté : l’éditeur s’engage à maintenir le point d’accroche, la charge de compatibilité reste bornée. Le troisième est la modification du comportement standard en dehors de ce modèle : cela fonctionne, et rien n’est promis. Le quatrième est la modification du cœur, en particulier du modèle de données : le plus profond, le moins visible depuis l’extérieur, et le plus coûteux.

Entre le premier niveau et le quatrième, l’écart est invisible pour celui qui formule la demande, et souvent voisin dans le devis immédiat. Il n’apparaît qu’à la version suivante. C’est toute la difficulté : le coût est différé, l’engagement est immédiat, et les deux ne sont pas portés par les mêmes personnes.

Le glissement suit toujours le même chemin. Chaque demande, prise isolément, est raisonnable, petite et peu chère. Celui qui l’arbitre ne détient pas le budget de la montée de version et ne sera probablement plus en poste quand elle sera payée. Personne ne tient le compte de l’accumulation, car il n’existe aucune ligne intitulée « écart au standard ». Et l’intégrateur est rémunéré pour satisfaire l’exigence, pas pour la refuser : refuser lui coûte une conversation difficile pour un bénéfice qu’il n’encaissera pas.

Les ateliers d’analyse d’écarts accélèrent le phénomène lorsqu’ils sont conduits sans discipline. Le métier y décrit le processus actuel, qui devient de fait l’exigence ; chaque différence avec le produit se convertit en écart à combler. La question qui n’est pas posée est pourtant la seule qui compte : cette différence mérite-t-elle d’être conservée ? La règle par défaut devrait être inverse — on adapte le processus, sauf lorsque la spécificité est une source de valeur défendue, nommée, et assumée par quelqu’un.

Deux dispositifs simples suffisent à tenir la ligne. Le premier est un budget d’écart décidé avant la sélection, et non après la démonstration : combien de divergence l’organisation est-elle prête à financer, et sur quelles sous-capacités en priorité. Le second est une traçabilité des écarts : chaque adaptation porte un propriétaire nommé, une raison écrite, son niveau sur l’échelle ci-dessus et une date de réexamen. Le chiffre à publier au comité de projet n’est pas le nombre de demandes traitées, mais le nombre d’écarts de niveau trois et quatre — le seul indicateur qui rende l’accumulation visible pendant qu’elle est encore réversible.

Enfin, un rappel utile en conception : les écarts les plus coûteux ne sont pas dans les écrans, ils sont dans le modèle de données. Étendre le modèle d’objets standard modifie ce que l’éditeur saura migrer, ce que le support saura qualifier, et ce que la version suivante pourra supposer.

Ce qui décide du coût réel : la version suivante

Pour un progiciel, la question déterminante n’est pas « saurons-nous en sortir ? » mais « saurons-nous passer à la version suivante, à un coût et à une cadence prévisibles ? ». C’est elle qui décide de tout le reste, parce qu’un progiciel qu’on ne peut plus faire évoluer devient un développement spécifique assorti d’un droit de licence : le cumul des inconvénients des deux options.

Pour un développement, la question déterminante n’est pas le coût initial mais qui le maintiendra la cinquième année. Construire engage une capacité permanente : garder des personnes qui comprennent le système, un socle technique qui vieillit, une documentation qui survit aux départs. C’est le vrai prix du spécifique, et il figure rarement dans la comparaison, parce qu’il ne prend pas la forme d’une facture identifiable.

Pour un service consommé en ligne, l’organisation hérite de l’entretien et perd la faculté de dire « pas maintenant » : la trajectoire du fournisseur et son calendrier deviennent les siens. C’est un transfert réel, et il joue dans les deux sens.

Ce que ces trois formulations ont en commun mérite d’être énoncé : acheter transfère un risque, cela n’en supprime aucun. On échange le risque de mal construire contre une dépendance aux priorités, à la longévité et à la politique tarifaire d’un tiers. Les deux sont légitimes ; en général, une seule des deux est instruite.

Instruire la décision

Le rôle de l’architecture, sur ce sujet, tient en quelques points fermes.

Cadrer avant d’ouvrir le marché, en décidant par sous-capacité plutôt que par domaine, sur un horizon explicite — et le même horizon pour les deux options comparées.

Écrire la politique d’écart avant la sélection, puis la rendre contractuelle avec l’intégrateur : ce qui compte comme configuration, ce qui relève du modèle d’extension, qui arbitre une demande qui sort du cadre, et à quel titre.

Juger les candidats sur leur modèle d’extension et sur leur historique de montées de version, et pas seulement sur la couverture fonctionnelle. Une grille fonctionnelle récompense le produit qui répond oui à tout — c’est-à-dire précisément celui qui laissera l’organisation creuser son propre trou.

Instruire la réversibilité tant qu’on dispose d’un pouvoir de négociation : export des données dans une forme documentée, propriété du paramétrage et des développements spécifiques, conditions de sortie. Après la signature, ces points ne se négocient plus.

Choisir le bon indicateur de succès. Trois ans après, la question pertinente n’est pas « le projet a-t-il tenu son budget ? » mais « à quel niveau de divergence sommes-nous, et que coûte la version suivante ? ».

Se conformer ou maintenir

Choisir le standard, c’est choisir de se conformer : accepter qu’une part de la façon de travailler soit définie à l’extérieur, par un éditeur et par ses autres clients. C’est très souvent la bonne décision — elle libère de l’attention pour les endroits où la différence produit réellement de la valeur. Mais elle doit être une décision, tenue et expliquée, et non la conséquence par défaut d’un tableau à deux colonnes.

Choisir le spécifique, c’est choisir de maintenir, durablement, et d’en accepter la charge organisationnelle bien plus que technique. C’est légitime là où la différence produit de la valeur, et coûteux partout ailleurs.

Les échecs observés ne viennent presque jamais du fait d’avoir retenu la mauvaise option. Ils viennent du fait de n’en avoir choisi aucune : acheter du standard en refusant de s’y conformer, ou construire du sur-mesure là où rien ne justifiait d’être différent. L’arbitrage est structurel parce qu’il répartit, pour des années, ce que l’organisation pourra changer seule et ce qu’elle devra négocier. Cette répartition mérite mieux qu’une comparaison de prix.