Faire ou faire faire : arbitrer entre logiciel du marché et développement sur mesure

La question revient à chaque projet de système d'information un peu conséquent : faut-il acquérir un logiciel existant sur le marché, quitte à adapter l'organisation à ses standards, ou développer une solution sur mesure, alignée précisément sur les processus de l'entreprise ? Ce choix, souvent réduit à une comparaison de devis, engage en réalité l'entreprise sur une durée de cinq à dix ans et mérite une grille de lecture plus large que le seul coût d'acquisition.

Le coût total, au-delà du prix d'achat

Un progiciel du marché affiche généralement un coût d'entrée maîtrisé et un délai de mise en œuvre plus court qu'un développement spécifique. Mais cette apparente économie initiale masque souvent des coûts récurrents substantiels : licences annuelles indexées sur le nombre d'utilisateurs, frais de maintenance évolutive facturés par l'éditeur, coûts de personnalisation à chaque montée de version. Sur un horizon de sept ans, il n'est pas rare que le coût total d'un progiciel dépasse celui d'un développement sur mesure équivalent en périmètre fonctionnel.

À l'inverse, un développement sur mesure engage des coûts initiaux plus élevés, une durée de mise en œuvre plus longue, et surtout une dépendance forte à l'équipe ou au prestataire qui l'a conçu. Cette dépendance, si elle n'est pas anticipée contractuellement, peut se transformer en risque majeur lorsque le prestataire cesse son activité ou que les développeurs clés quittent l'entreprise cliente.

Le critère décisif : la singularité du processus métier

Le critère le plus fiable pour trancher n'est ni le budget ni le délai, mais la singularité réelle du processus métier concerné. Pour des fonctions largement standardisées d'un secteur à l'autre — comptabilité générale, paie, gestion de la relation client de base — un progiciel du marché offre presque toujours un meilleur rapport qualité-coût, car il bénéficie des retours d'expérience de centaines d'entreprises et d'une maintenance mutualisée.

En revanche, dès qu'un processus constitue un véritable avantage concurrentiel — un algorithme de tarification dynamique, une logique d'allocation de stock propre à un modèle logistique spécifique, un parcours client différenciant — l'adaptation à un progiciel standard revient à renoncer à cet avantage pour se conformer à une logique générique. Nous avons vu des entreprises perdre, en voulant faire rentrer leur modèle dans un progiciel, précisément ce qui les différenciait de leurs concurrents.

Choisir un progiciel standard pour son cœur de différenciation revient à louer sa stratégie à un éditeur qui la vend aussi à vos concurrents.

L'option hybride, souvent la plus pertinente

Dans la pratique, l'arbitrage le plus fréquent n'est ni le tout progiciel ni le tout sur mesure, mais une architecture hybride : un socle de progiciels du marché pour les fonctions standardisées, complété par des développements spécifiques sur les processus réellement différenciants, reliés entre eux par des interfaces de programmation. Cette approche demande une compétence d'architecture logicielle solide, souvent absente en interne dans les PME, ce qui explique pourquoi elle reste sous-utilisée malgré ses avantages.

Elle présente néanmoins un risque propre : la multiplication des points d'intégration augmente la complexité de maintenance et la surface de risque en cas de panne. Une gouvernance claire des interfaces, avec une documentation à jour et un responsable technique identifié pour chaque interconnexion, est indispensable pour que cette architecture reste pilotable dans la durée.

Réversibilité et gouvernance des données

Quel que soit le choix retenu, deux exigences contractuelles doivent être posées dès l'origine. La première concerne la réversibilité : l'entreprise doit s'assurer qu'elle pourra, à tout moment, récupérer l'intégralité de ses données dans un format exploitable, sans dépendre de la bonne volonté de l'éditeur ou du prestataire. La seconde concerne la propriété du code en cas de développement spécifique : sans clause explicite de cession des droits, l'entreprise peut se retrouver, plusieurs années après le projet, dans l'incapacité juridique de faire évoluer son propre outil avec un autre prestataire.

Ces deux points, souvent négociés à la marge tant l'urgence opérationnelle domine au moment du lancement, déterminent en réalité la marge de manœuvre de l'entreprise pour les dix années suivantes. Un arbitrage technologique bien conduit ne se mesure donc pas seulement à la qualité de l'outil livré, mais à la liberté qu'il préserve pour l'avenir.