Progiciel ou développement spécifique

Les systèmes informatiques sont la colonne vertébrale de la plupart des entreprises. Celles-ci dépensent quelques pourcents de leur chiffre d’affaire à construire et opérer ces systèmes informatiques. Un système classique vivra une décennie, et parfois beaucoup plus avant d’être remplacé. Il y a deux grandes stratégies pour déployer un système informatique: faire appel à un progiciel ou développer une application spécifique. Ce choix est structurant pour l’entreprise.

Progiciel

Un progiciel fournit une solution clé en main pour un processus métier. Un logiciel de comptabilité vous fournit directement une solution pour enregistrer vos écritures, créer des factures, et même faire des déclarations fiscales. Les progiciels permettent parfois, d’adapter la solution à vos besoins, mais il y a toujours une limite. Peu de progiciels ont développé des interface de qualité permettant des extensions puissantes. Pourtant, c’est qui est courant dans d’autres industries: wordpress est ainsi connu pour ses plug-ins complexes, et de nombreux jeux videos proposent le développement d’extensions et de modifications.

Développement spécifique

Dans un développement spécifique, votre équipe technique implémente directement la logique métier souhaitée. Ces développements sont réalisés sur la base d’une infrastructure technique générique qui ne connait rien de vos besoins métiers. L’élement essentiel est une base de données qui stocke vos données de façon sécurisée et permet un accès à plusieurs utilisateurs en parallèle. Il existe maintenant des composants open-source stables et de qualité pour la plupart des éléments de l’infrastructure technique nécessaire au développement d’applications. Vous pouvez donc dévevlopper exactement les processus avec les règles métiers que vous définissez, ce qui est précieux si vous avez des besoins spécifiques.

Bien que l’infrastructure de base soit standardisée, les développements spécifiques néccessitent néanmoins de redévelopper à chaque fois des fonctiosn de base qui n’ont pas été encore standardisées. Typiquement, un tel logiciel a besoin de workflow, de sécurité, de contrôle d’accès, ainsi que de mise en page des données. Les plate-formes ‘lowcode’ (aussi appelées atelier de génie logiciel) peuvent aider, en fournissant ces briques prêtes à l’emploi. Open Lowcode est une plate-forme lowcode complètement open-source, qui fournit ces briques, et laisse les développeurs implémenter le ‘ciment’, la logique spécifique à votre application.

Quelle stratégie choisir

Lorsque vous avez à créer une nouvelle application métier, ou remplacer une ancienne application, vous devez décider de la stratégie à mettre en place. Cet article suggère une méthodologie.

Taille de l’application

Le premier critère pour décider d’une stratégie est la taille du sujet. Elle doit être mise en contexte de budget informatique de l’entreprise, qui représente typiquement un pourcentage fixe du chiffre d’affaire constant par industrie. Par exemple, un budget informatique de 100M€ est typique pour une entreprise ayant plusieurs milliards d’euros de chiffre d’affaire. Nous classons les systèmes comme

Enormes si le coût de développement et déploiement représente plusieurs années de budget informatique;
Gros si le coût de développement et déploiement représente une année de développement informatique;
Petits si le coût de développement et déploiement représente beaucoup moins qu’un an de budget informatique.

Il y a une limite naturelle aux nombres de projets que vous pouvez entreprendre. Typiquement, vous pouvez vous permettre de développer un gros système tous les 3 à 5 ans, et quelques petits systèmes par an.

Impact Métier

Nous proposons de classer les systèmes informatiques en plusieurs catégories, en fonction de l’impact métier, et de l’aspect normé du sujet.

Un système stratégique est critique pour la position compétitive de votre entreprise, et vous souhaitez donc pouvoir innover et être le plus agile possible. Si votre entrerprise prétend être une référence dans le domaine logistique, vous aurez probablement besoin de votre propre système de gestion logistique, vous permettant de déployer rapidement vos innovations propriétaires.
Un système normé implémente un processus qui respect une norme. Le processus normé typique est la comptabilité, il existe en effet des lois et des normes que toute entreprise doit respecter. Les normes légales ne sont pas les seules: il existe aussi des normes scientifiques et technologiques: ainsi, les alliages d’acier sont normalisés, et leur propriétés mécaniques le sont également. Il est toutefois nécessaire d’être prudent: il existe aussi de “fausses normes”. Ces dernières sont pourtant déclarées auprès d’un organisme officiel, mais elles ne sont pas respectées dans les fait. Souvent, ce sont des marottes d’employés de grands groupes, ou des coups marketings: certaines entreprises déclarent leurs formats internes comme standards, mais personne d’autre ne les utilisent. Il est fortement recommandé de vérifier la réalité d’une norme ou d’un standard en demandant l’avis de plusieurs experts venant d’horizons différent.
La plupart des applications ne sont ni stratégiques ni normées. Elles peuvent néanmoins être critiques pour la productivité de l’entreprise. Dans cette catégorie, on trouve les suites bureautiques, des systèmes industriels, RH…

Retours d’expérience

Pour proposer une stratégie adaptée, les faits suivants doivent être pris en compte

Certains progiciels sont très chers même s’ils apportent peu de valeur. Dans un marché parfait, le prix d’un produit simple devrait être bas, et une vieille technologie devrait très vite baisser de prix. Mais les vendeurs de progiciels dépensent beaucoup d’énergie à garder des prix élevés dans un marché qui comprend principalement des transitions de gré à gré. Il est ainsi important de remettre systématiquement en cause la valeur apportée réellement par un progiciel en fonction de son prix.
En utilisant un progiciel, vous dépendez de la feuille de route de l’éditeur. Cela veut dire notamment faire une mise à jour douloureuse toutes les quelques années. Les développements spécifiques ont aussi des problèmes d’obsolescence des technologiques de base utilisées, mais cela est en général beaucoup moins difficile. Pour prendre un exemple, changer de version de base de données est relativement simple.
On sousestime toujours le coût de développer un logiciel, ou d’adapter un logiciel existant. En particulier, il faut toujours prévoir une phase de stabilisation pour qu’un logiciel monte en qualité. cela représente souvent de 30 à 100% de l’investissmeent initial. Si vous gardez un système existant, ou si vous utilisez comme cela est prévu un progiciel, cce traail de stabilisation est déjà derrière vous.
Certains sujets sont simplement trop gros pour votre entreprise, et plus votre entreprise est petite, plus il y a de tels sujets. Pour ces sujets, vous devez acheter avec discernement un progiciel existant, et vous en contenter. Cela peut limiter la stratégie de votre entreprise et vous interdire d’innover dans certains domaines. C’est très important, et très rare, que les entreprises reconnaissent cet état de fait, et adaptent en fonction leur stratégie.

La matrice magique

Voici donc finalement les recommendations pour le choix de la stratégie

Les progiciels sont la solution pour tous les sujets normés gros et énormes. Le meilleur exemple est une suite de comptabilité;
Les progiciels sont également la bonne solution pour les sujets énormes qui ne sont ni normés ni stratégiques, comme le développement d’un système sur ces sujets est hors de portée. Par exemple, vous n’avez pas les moyens de redévelopper une suite bureautique, c’est un investissement énorme. Vous devez juste acheter intelligemment un produit existant, et accepter ses limitations;
Si un sujet énorme est aussi stratégique, la situation est délicate. L’entreprise peut considérer qu’un investissement stratégique, dépassant de loin le budget informatique normal est nécessaire. Vous pouvez aussi créer un partenariat avec un vendeur de progiciel pour qu’il incorpore vos besoins. Comme vous serez très dépendant de ce fournisseur, il est probablement sage de limiter le parternariat au périmètre minimum;
Les sujets stratégiques petits et gros doivent absolument faire l’objet d’un développement spécifique. Vous obtiendrez exactement ce dont vous avez besoin, et vous aurez plus de flexibilité. Open Lowcode est une plateforme très efficace pour vos développements spécifiques;
Pour les autres sujets (sujets normés simples) et les autres sujets petits et gros, vous pouvez opter pour un progiciel ou un développement spécifique. Cette catégorie comprend une partie importante des ERP. Les entreprises adaptent souvent fortement leurs ERP pour prendre en compte leur spécificité, mais les ERP ne sont pas stratégiques, car les fonctions supportées (finance, logistique…) ne sont pas vraiment différenciantes, juste des sujets sur lesquels il ne faut pas “se planter”. Une approche intelligente est de faire une tentative de développement spécifique, en réalisant un prototype. Vous pouvez par exemple investir 10% du budget initial dans un protoype, et regarder jusqu’où le développement spécifique peut aller. Cela vous donnera une bonne idée de la complexité du sujet, et des capacités de votre écosystème de développement. Ce dernier point est un facteur de décision majeur pour partir dans une voie spécifique. Avec Open Lowcode, vous avez besoin de moins de compétences techniques, car l’outil fournit déjà une bonne base technique, et guidera vos développeurs.

Les développements spécifiques seront réalisés par vos équipes, mais les progiciels sont vendus par leurs éditeurs. Vous n’allez donc pas comparer les deux approches dans des conditions justes et équilibrées. En effet, le progiciel disposera d’avocats professionnels, puissants et intéressés: les vendeurs des éditeurs. Ils chercheront à vendre à tout prix car ils touchent une commission pour cela, et même s’ils ne proposent pas la solution idéale, personne ne saura après coup qu’un autre approche aurait été trois fois moins chère. Et nous pourrions évoquer aussi l’adage que “personne dans une DSI n’a jamais été licencié pour avoir choisi un des leaders du marché”, que la plupart des collaborateurs de DSI ont probablement en tête. Pour compenser ces biais et aprioris, il est probablement approprié de faire légèrement pencher la balance du côté des développements specifiques, et d’être l’avocat du diable lorsque la solution progicielle est évoquée. Au minimum, c’est une bonne idée d’avoir réalisé quelques hackathons avant de prendre une décision irrévocable.