Frankenstack : quand votre SI devient un monstre recousu

Posez la question suivante à votre équipe : qui, chez nous, est capable de dessiner sur une feuille tous nos outils et la façon dont ils communiquent entre eux ?
Dans la grande majorité des PME, la réponse est : personne. Pas parce que l'équipe manque de compétence, mais parce que ce schéma n'a jamais été conçu. Il s'est accumulé. Chaque brique a été ajoutée pour une bonne raison, à un moment donné, par quelqu'un qui résolvait un problème réel. L'ensemble, lui, n'a été décidé par personne.
Ce résultat porte un nom dans le vocabulaire des architectes de systèmes : un frankenstack.
Définition
Un frankenstack est un système d'information composé de solutions ponctuelles qui ne fonctionnent pas comme un système. Les outils sont reliés entre eux par des intégrations natives, des connecteurs d'automatisation, des exports programmés, des scripts et — le plus souvent — des copier-coller humains devenus permanents.
La caractéristique déterminante est celle-ci : les pannes n'arrivent pas dans les applications, elles arrivent dans les jointures. Chaque outil, pris séparément, fonctionne parfaitement. C'est l'espace entre eux qui casse, et c'est justement l'espace que personne ne surveille.
Le terme est né dans l'univers du marketing et du commerce, où l'empilement d'outils spécialisés est le plus visible. Il décrit tout aussi bien le système d'information d'une PME de 40 personnes qui a grandi par ajouts successifs.
Sept symptômes de diagnostic
Le frankenstack ne se diagnostique pas par un audit technique mais par des signes de fonctionnement quotidien. Comptez les vôtres.
- Personne ne peut cartographier l'ensemble. Le test d'ouverture de cet article. S'il échoue, tous les autres symptômes suivent généralement.
- Une mise à jour extérieure vous casse quelque chose. Un éditeur fait évoluer son API, une synchronisation s'arrête, et personne ne le remarque avant plusieurs jours — parce que rien ne surveille cette jointure.
- Aucune source de vérité désignée. Interrogez trois personnes sur le nombre de clients actifs : vous obtenez trois chiffres, tous défendables.
- Une réconciliation manuelle est intégrée au processus. Quelqu'un, chaque mois, recoupe deux exports pour produire un troisième fichier. Cette tâche n'est écrite nulle part et pourtant tout en dépend.
- La même donnée est saisie deux fois. Un nouveau client est créé dans le CRM, puis recréé dans la facturation. Deux saisies, deux orthographes, deux vérités.
- Les intégrations sont point-à-point. Chaque outil parle directement à trois autres. Avec dix outils, cela fait potentiellement quarante-cinq liaisons à maintenir, dont vous n'en connaissez qu'une dizaine.
- Une personne est le point de passage obligé. Il existe quelqu'un — souvent l'office manager ou le bras droit du dirigeant — dont l'absence de deux semaines bloque la production des chiffres. Ce n'est pas une force, c'est une dépendance non documentée.
Trois symptômes ou moins : système hétérogène mais gouvernable. Quatre à cinq : frankenstack installé, le coût est déjà significatif. Six ou plus : la moindre évolution est risquée, et le sujet doit remonter au niveau du comité de direction.
Pourquoi il se forme, et pourquoi c'était rationnel
Il faut insister sur ce point, parce qu'il conditionne la façon d'en sortir : un frankenstack n'est pas le produit de mauvaises décisions. Il est le produit de bonnes décisions locales prises sans arbitrage global.
Le commercial avait besoin d'un CRM : décision juste. La comptabilité avait besoin d'un logiciel adapté : décision juste. Les RH avaient besoin d'un outil de congés : décision juste. Chaque choix a été fait par la personne la mieux placée pour le faire, avec le bon critère — l'excellence dans son domaine. Aucun n'a été fait avec le critère « comment cette brique parlera-t-elle aux autres », parce que ce critère n'est le sujet de personne en particulier.
Les chiffres de parc applicatif donnent la mesure du phénomène : environ 93 applications par entreprise en moyenne selon les mesures d'Okta, plus de 200 au-delà de 2 000 salariés, et une part minoritaire — souvent estimée autour du quart — réellement intégrée aux autres. Côté dépenses, les analyses convergent sur 25 à 30 % de gaspillage dans les portefeuilles logiciels non gouvernés.
Ce que ça coûte vraiment
Le coût du frankenstack ne se lit pas sur la ligne « logiciels » du compte de résultat. Il se répartit sur quatre postes, tous invisibles.
Le travail de raccordement. Les heures passées à exporter, recouper, ressaisir et vérifier. Elles sont assurées par les gens les plus chers de l'entreprise, et n'apparaissent dans aucun suivi d'activité.
La fragilité. Chaque jointure est un point de rupture potentiel. Le coût n'est pas la panne elle-même : c'est le délai avant détection, pendant lequel des décisions se prennent sur des données périmées.
L'immobilisme. Dans un frankenstack mûr, changer un outil devient un projet à risque parce que personne ne sait ce qui en dépend. L'entreprise conserve alors des solutions qu'elle sait inadaptées — non par attachement, mais par peur de ce qui casserait.
L'IA rendue inopérante. C'est le coût nouveau, et le plus lourd à moyen terme. Un assistant IA branché sur un frankenstack hérite de toutes ses contradictions : trois définitions du client actif, deux orthographes par société, des données de fraîcheur inégale. Il ne signale pas le conflit — il tranche silencieusement et répond avec assurance. Le frankenstack ne rend pas l'IA impossible : il la rend fausse, ce qui est pire.
Comment en sortir sans tout refaire
La tentation du grand remplacement — un ERP unique, une refonte complète — se heurte à la réalité budgétaire et opérationnelle d'une PME. Ce n'est de toute façon pas nécessaire. La méthode qui fonctionne procède par couches, dans un ordre précis.
Étape 1 — L'inventaire honnête
La liste complète des outils, à partir des relevés bancaires et non de la mémoire. Pour chacun : le coût annuel, le propriétaire métier, les données qu'il produit, et ce à quoi il est relié. Cet exercice prend une demi-journée et révèle systématiquement deux ou trois abonnements que plus personne n'utilise.
Étape 2 — Désigner les systèmes de référence
Pour chaque domaine de données — client, commande, facture, collaborateur, produit — un seul système fait foi. Un seul. Cette décision est politique autant que technique, elle se prend en comité de direction, et elle est la plus structurante de tout le chantier. Les autres systèmes deviennent des consommateurs de cette référence.
Étape 3 — Réconcilier les identifiants
« Martin SAS », « SAS MARTIN » et le client 4471 doivent devenir la même entité, automatiquement. C'est le travail le plus ingrat et le plus rentable de la séquence : c'est lui qui supprime la réconciliation manuelle mensuelle.
Étape 4 — Faire converger plutôt que remplacer
Vos outils métier restent en place : ils sont bons dans leur domaine. Ce qui change, c'est que la donnée qu'ils produisent converge vers un point unique, structurée et définie. Vous ne consolidez pas les applications, vous consolidez la donnée. C'est ce qui rend le chantier accessible à une PME — quelques semaines au lieu de plusieurs trimestres.
Étape 5 — Instaurer une règle d'entrée
Sans gouvernance, le frankenstack se reforme en dix-huit mois. La règle minimale tient en une phrase : tout nouvel outil doit indiquer, avant souscription, quelle donnée il produit, avec quel système il se raccorde, et qui en est propriétaire. Trois questions, posées une fois. Elles suffisent à empêcher la reconstitution du monstre.
Par où commencer
- Faites le test de la feuille en comité de direction : demandez à chacun de dessiner le système d'information. Comparer les schémas est l'exercice de diagnostic le plus rapide qui soit.
- Comptez vos symptômes dans la liste des sept. Le score détermine l'urgence, pas votre intuition.
- Désignez vos systèmes de référence sur les trois domaines qui comptent le plus — probablement client, facture et collaborateur. C'est une décision, pas un projet.
- Identifiez la réconciliation manuelle la plus coûteuse et automatisez celle-là en premier. Le gain est immédiat et rend le reste du chantier finançable.
Un frankenstack n'est pas un échec de gestion : c'est ce que produit une entreprise qui a grandi en résolvant ses problèmes au fur et à mesure. Il devient un vrai problème le jour où l'on veut poser des questions transverses — ou brancher une IA. À ce moment-là, la couche qui manque n'est pas un outil de plus. C'est un endroit où la donnée se rejoint enfin.

