Schéma directeur du SI industriel : aligner le système d’information sur la stratégie industrielle

Dans l’industrie, le système d’information ne se contente plus de soutenir les opérations : il conditionne la capacité à produire, à livrer et à se transformer. Le schéma directeur du SI industriel est l’outil qui permet de décider, en connaissance de cause, de ce que l’on transforme, dans quel ordre et pour quelle valeur.

Ouvrez la cartographie applicative de la plupart des groupes industriels et vous lirez leur histoire.  

→ Un ERP choisi il y a quinze ans et modernisé par étapes.

→ Un MES déployé sur les deux usines les plus récentes.

→ Un WMS propre à l’entrepôt principal, une GMAO différente sur chaque site, et une constellation de fichiers Excel devenus critiques sans que personne ne l’ait décidé.

Chacune de ces briques a eu de bonnes raisons d’exister. Ensemble, elles produisent un SI difficile à faire évoluer, coûteux à maintenir et qui peine à donner une vision consolidée de la performance.

Le schéma directeur du SI industriel sert à sortir de cette accumulation. Non pas en dressant une liste de projets informatiques, mais en répondant à une question de direction générale : de quelles capabilités métier l’entreprise a-t-elle besoin pour tenir sa stratégie industrielle, quel système d’information doit les soutenir, et comment y parvenir sans mettre la production en risque ?

Notre parti pris est simple : un schéma directeur des systèmes d’information industriel se juge aux décisions qu’il rend possibles. C’est sous cet angle que nous l’abordons ici, de l’analyse des enjeux jusqu’à la gouvernance de la trajectoire. Les principes généraux d’un SDSI sont détaillés dans notre guide du schéma directeur des systèmes d’information.

Les notions clés

Quelques repères de vocabulaire, car un schéma directeur n’est utile que si tous les acteurs parlent le même langage.

Pourquoi le SI industriel exige son propre schéma directeur

Un schéma directeur « générique » raisonne en applications, en coûts et en alignement métier. Dans l’industrie, ce n’est pas suffisant, parce que le SI y est soumis à des contraintes que l’on ne rencontre pas, ou beaucoup moins, dans une banque ou un distributeur.

La première est le temps. Dans une usine, le SI vieillit au rythme des machines, pas à celui des éditeurs. Il n’est pas rare de trouver une ligne pilotée par un poste de supervision dont le système d’exploitation n’est plus maintenu depuis des années, simplement parce que l’arrêter coûterait plus cher que le risque qu’il fait courir. Le schéma directeur doit dire quels équipements nous modernisons, lesquels nous isolons, et à quelle occasion (arrêt annuel, changement de série) nous intervenons.

La deuxième est l’hétérogénéité. Les groupes industriels se construisent par acquisitions et par investissements successifs : deux usines du même groupe peuvent tourner sur des ERP, des MES et des architectures OT différents. Cette diversité n’est pas un problème en soi. Elle le devient quand elle empêche de consolider les données, multiplie les compétences rares à maintenir ou rend impossible le déploiement d’un standard.

Vient ensuite la disponibilité, qui change la nature du risque : une indisponibilité applicative peut arrêter une ligne, bloquer des expéditions ou rompre une traçabilité réglementaire. S’y ajoutent la convergence IT/OT, qui multiplie les échanges entre gestion - atelier et donc les surfaces d’exposition, la pression sur la donnée industrielle, que l’on attend désormais fiable, comparable entre sites et disponible au plus près du temps réel, et enfin la nécessité d’une vision de bout en bout : améliorer la production ne sert à rien si la planification reste fragile ou si l’entrepôt devient le goulet d’étranglement.

Ce que nous observons sur le terrain :

Le scénario se répète d’un groupe à l’autre. Prenons un industriel de taille intermédiaire, cinq usines, construit en partie par acquisitions. Le diagnostic recense près de 150 applications, dont une quarantaine de développements locaux et autant de fichiers Excel devenus critiques sans que personne ne l’ait décidé. En creusant, on découvre que la traçabilité réglementaire d’une usine repose sur une application développée en interne il y a quinze ans. Elle est hébergée sur un serveur dont le système d’exploitation n’est plus maintenu, et une seule personne, proche de la retraite, sait encore la faire évoluer.

Le réflexe aurait été de lancer immédiatement un projet MES groupe. La décision a été plus progressive : isoler le serveur sur un segment réseau dédié, documenter l’application et organiser le transfert de compétences. Ensuite seulement, la reprise de la traçabilité a été inscrite dans le core model MES, en commençant le déploiement par le site le plus exposé.

Résultat : le risque le plus critique a été traité en quelques semaines, sans attendre le programme de fond, et le MES a démarré là où il créait le plus de valeur.

Les signaux qui doivent déclencher la démarche

Le déclencheur le plus fréquent reste un grand programme applicatif : renouvellement de l’ERP, déploiement d’un MES multisite, refonte du WMS ou projet S&OP.  
Logique : ces programmes engagent des choix de processus, de référentiels et de responsabilités pour une décennie. C’est aussi le moment où le schéma directeur est le plus utile, à condition de le mener avant de choisir la solution et non pour justifier un choix déjà fait.

D’autres signaux sont moins visibles et souvent plus révélateurs. Une acquisition qui fait coexister plusieurs modèles applicatifs. Une équipe IT qui consacre une part croissante de son temps au maintien des environnements historiques. Un comité où la DSI et les directions métier ne parviennent plus à arbitrer, pendant que les demandes locales et le shadow IT se multiplient. Ce dernier signal est le plus sous-estimé : il indique moins un problème d’outils qu’une absence de vision partagée.

Ce qu’un schéma directeur doit permettre de trancher

Un bon schéma directeur se reconnaît aux décisions qu’il rend possibles, pas à son épaisseur. Il doit répondre à six questions, dans cet ordre.

L’ordre compte. Partir des enjeux industriels plutôt que de la technologie évite de construire une cible autour d’une solution. Mesurer l’écart entre le SI actuel et ces enjeux évite de remplacer ce qui fonctionne encore. Et ne parler d’investissements qu’une fois la cible clarifiée évite que la roadmap soit dictée par l’urgence du moment ou par l’enveloppe budgétaire disponible.

Une dimension traverse ces six questions : la conduite du changement. Un schéma directeur industriel modifie le quotidien de populations très différentes. Le planificateur change d’outil, le chef d’équipe de rituels, l’opérateur de gestes, et le key user devient un relais qu’il faut former et rendre disponible. Ces impacts s’identifient dès le diagnostic, population par population, et pèsent dans la priorisation au même titre que le coût ou la complexité. Une trajectoire qui néglige la capacité des équipes à absorber le changement peut être parfaitement conçue sur le papier et échouer sur le terrain.

En pratique, deux de ces questions concentrent l’essentiel des débats, et donc de la valeur : la répartition des responsabilités entre applications, et le niveau de standardisation entre sites. Nous y revenons plus bas.

Raisonner en capabilités, pas en applications

La différence tient en deux questions. La logique applicative demande : « Quel outil devons-nous remplacer ? ». La logique par capabilités demande : « Qu’est-ce que l’entreprise doit mieux savoir-faire ? ». La seconde produit de meilleures décisions, et un exemple suffit à le montrer.

Une direction industrielle veut améliorer sa traçabilité et envisage un MES. Le diagnostic révèle que les ruptures viennent d’ailleurs : nomenclatures incohérentes entre bureau d’études et production, identifiants articles différents d’un site à l’autre, WMS mal synchronisé avec l’ERP, processus qualité non standardisé. Le MES aurait traité une partie du problème, au prix d’un investissement lourd, sans régler l’essentiel. Raisonner en capabilités, ici « tracer un lot de bout en bout », oblige à regarder toute la chaîne nécessaire au résultat.

Cette approche vient de l’architecture d’entreprise. Une capabilité métier décrit ce que l’entreprise sait faire, indépendamment de la façon dont elle le fait : qui, avec quel processus, sur quelle application. C’est cette stabilité qui la rend utile : les organisations changent, les outils aussi, mais « planifier la production » ou « tracer un lot » restent. Une carte des capabilités, structurée en deux ou trois niveaux de détail, devient alors le référentiel commun du schéma directeur. Son premier niveau reprend souvent les grands processus de bout en bout, que l’on décline ensuite : l’order-to-cash (O2C), par exemple, se décompose en prise de commande, gestion du crédit, exécution logistique, facturation et recouvrement. On y rattache les applications, ce qui fait apparaître les redondances et les trous de couverture ; on y évalue la maturité, ce qui donne la heatmap ; et on y adosse les investissements, pour savoir quelle capabilité chaque projet améliore réellement.

C’est aussi ce qui permet d’objectiver la maturité. Une heatmap des capabilités, évaluée selon quelques dimensions (processus, données, couverture fonctionnelle, usages, standardisation, risques), fait souvent apparaître le même profil : des lignes bien automatisées, mais des référentiels et des données de production mal maîtrisés. Dans ce cas, ajouter de la technologie ne résout rien ; c’est la gouvernance des données qu’il faut traiter d’abord.

L’écosystème applicatif : une carte, pas un catalogue

ERP et MES structurent la plupart des SI industriels, mais ils n’en sont qu’une partie. Un schéma directeur doit couvrir la chaîne complète, de la planification au pilotage, et les couches transverses qui la font tenir.

Son rôle n’est pas de conclure qu’il faut une APS, un WMS, un TMS, un PLM et une GMAO. Ce serait l’inverse de la démarche. Pour chaque capabilité, il répond à trois questions : faut-il la couvrir, quelle application en est responsable, et comment échange-t-elle avec les autres ? C’est le cœur de l’urbanisation du SI industriel, et le meilleur moyen de supprimer les zones grises, les doubles saisies et les interfaces inutiles.

Pour les industriels qui commercialisent des catalogues étendus, l’enjeu se concentre sur les référentiels de données, à commencer par le référentiel article. Le PLM porte les données de conception, l’ERP les données de gestion, le PIM les informations commerciales diffusées aux distributeurs et le DAM les visuels, notices et certificats. Chacun est légitime sur son périmètre, mais sans gouvernance des données de référence (MDM) qui désigne, attribut par attribut, quel système fait foi, la même référence finit décrite de quatre façons différentes. C’est souvent là que se cache le premier chantier du schéma directeur, bien avant le choix d’un nouvel outil.

Les processus de bout en bout, qui structurent souvent le premier niveau de la carte des capabilités, offrent une grille de lecture complémentaire. Order-to-cash, procure-to-pay, plan-to-produce, design-to-release : ces flux traversent plusieurs applications et plusieurs directions. Une commande client passe par l’ERP, le WMS, le TMS puis la facturation ; une interface mal maîtrisée à l’une de ces étapes se paie en retard de livraison ou en litige client. Analyser le SI processus par processus fait apparaître les ruptures que la cartographie applicative masque, et donne à chaque flux un responsable métier, pas seulement un responsable applicatif.

Les processus de bout en bout les plus structurants dans l’industrie sont les suivants :

Le livrable le plus utile à ce stade est souvent un simple tableau de responsabilités. Il paraît évident ; il ne l’est presque jamais. Voici les questions que nous posons systématiquement, et la réponse la plus fréquente, à adapter à chaque contexte.

Standardiser sans étouffer les sites

Dans un groupe multisite, la standardisation est le sujet le plus sensible du schéma directeur SI. Les directions centrales y voient des économies d’échelle, une meilleure maîtrise des données et des déploiements plus rapides. Les directeurs d’usine y voient le risque de perdre la souplesse dont ils ont besoin pour tenir leurs engagements. Les deux ont raison, ce qui explique pourquoi le débat tourne en rond tant qu’il reste posé en termes de « centralisation ou autonomie ».

La sortie consiste à définir explicitement trois niveaux. Le socle (architecture, intégration, référentiels critiques, cybersécurité) est standardisé partout, parce qu’il conditionne la capacité des systèmes à fonctionner ensemble. Les grandes applications métier, l’ERP en tête, relèvent d’un cadre commun adaptable : un core model groupe, complété de paramétrages et de localisations par site. Enfin, certains outils peuvent rester locaux, à condition que leur différence soit justifiée par le procédé, le produit, le marché ou la réglementation, et qu’ils soient documentés et réversibles.

Notre conviction : le risque n’est pas l’autonomie locale, mais l’autonomie non gouvernée. Et une standardisation imposée sans associer les sites produit l’effet inverse de celui recherché. Quand l’outil central ne colle pas au terrain, les équipes contournent : fichiers Excel, macros, bases locales. La standardisation fabrique alors du shadow IT. La parade est simple à énoncer et exigeante à appliquer : associer les sites dès la conception de la cible, et distinguer les différences utiles de celles qui ne sont que l’héritage de l’histoire.

Ce que nous observons sur le terrain

Un groupe de huit usines engage le remplacement de ses trois ERP historiques. La première intention de la direction est claire : un modèle unique, identique partout. Les ateliers avec les sites montrent vite les limites de cette ambition. La gestion des commandes, des achats, des stocks et la finance peuvent effectivement être communes. Mais deux usines travaillent à la commande sur des produits configurés, quand les autres produisent sur stock en grande série, et une troisième est soumise à des exigences de traçabilité réglementaire propres à son marché.

Le core model retenu couvre environ 80 % des processus. Les adaptations sont limitées à trois cas, chacun justifié et documenté : la configuration produit pour les sites à la commande, la gestion des lots renforcée pour le site réglementé et quelques localisations fiscales. Tout le reste, y compris des habitudes locales défendues avec conviction, rejoint le standard.

Le premier déploiement est le plus long, car c’est lui qui stabilise le modèle. Les vagues suivantes vont nettement plus vite : on ne redessine plus les processus, on paramètre et on forme.

Le socle : données, intégration et cybersécurité IT/OT

C’est la partie la moins visible du schéma directeur, et celle qui conditionne toutes les autres.

Sur la donnée, le constat est presque toujours le même : les projets analytics échouent moins par manque d’outils que par manque de maîtrise des données sources. Avant d’investir dans une plateforme data ou dans l’IA, le Schéma directeur des Systèmes d’Information doit désigner un système de référence par donnée, nommer les responsables des référentiels et fixer un niveau de qualité compatible avec les usages. Une plateforme ne compense pas durablement des données opérationnelles mal tenues.

Sur l’intégration, l’objectif est de sortir des interfaces point à point qui se sont accumulées au fil des projets. Des règles d’échange communes et une plateforme d’intégration font partie du socle, au même titre que les référentiels.

Sur la cybersécurité, l’industrie a une particularité : la disponibilité et l’intégrité y comptent souvent autant que la confidentialité. Le modèle en niveaux de l’ISA-95 et la norme IEC 62443 fournissent un cadre éprouvé pour segmenter les réseaux et organiser la coopération entre équipes IT et OT. La directive européenne NIS2 étend par ailleurs les obligations de cybersécurité à de nombreux secteurs industriels. Dans tous les cas, la sécurité doit être pensée comme une exigence transverse, intégrée dès la conception de la cible, et non comme un projet à part.

Enfin, la répartition entre systèmes locaux, edge, datacenter et cloud ne relève pas d’une préférence. Certaines fonctions d’atelier doivent continuer à tourner sans connexion ; d’autres gagnent à être mutualisées. C’est le besoin, le risque et le coût qui tranchent, fonction par fonction.

De la cible à la roadmap : séquencer pour durer

Une bonne cible peut échouer avec une mauvaise roadmap. La difficulté n’est pas d’identifier les projets, mais de les séquencer.

Trois contraintes sont systématiquement sous-estimées. Les dépendances d’abord : lancer un projet data sans référentiels maîtrisés, ou un MES sans socle d’intégration, revient à construire sur des sables mouvants. La capacité d’absorption ensuite : ce sont les mêmes experts métier qui sont sollicités par l’ERP, le MES et le WMS, et une roadmap qui superpose trois programmes structurants sur les mêmes équipes produit des retards et de l’épuisement, même si elle est techniquement faisable. Le calendrier industriel enfin : certaines bascules ne sont possibles que pendant un arrêt technique, un inventaire ou une période de faible activité, et ces fenêtres doivent être posées dans la roadmap dès le départ.

Une trajectoire crédible combine quelques résultats rapides (un tableau de bord commun, la suppression d’une double saisie, la fiabilisation d’une interface fragile) et des chantiers de fond. Les premiers entretiennent l’adhésion des métiers ; les seconds préparent l’avenir. Une roadmap faite uniquement de chantiers techniques perd le soutien du terrain avant d’avoir produit sa valeur.

Pour la direction générale, la forme la plus utile est souvent celle de trois scénarios budgétaires : un scénario socle qui traite les risques et les prérequis, un scénario cible qui réalise la trajectoire recommandée, et un scénario accéléré qui renforce les capacités d’exécution. Le schéma directeur devient alors un véritable outil d’arbitrage, et non un document à valider.

Gouverner et mesurer la valeur

Un schéma directeur publié puis rangé perd sa valeur en quelques mois : les priorités changent, un site est racheté, un projet dérape. Ce qui le fait vivre, c’est une gouvernance simple, à trois niveaux, et une revue périodique de la trajectoire.

Le comité stratégique vérifie l’alignement avec la stratégie et arbitre les investissements structurants. Le niveau portefeuille et architecture suit les projets, les budgets et les dépendances, et garantit le respect de la cible. Les projets et les sites exécutent. Data, cybersécurité et IT/OT se gouvernent de manière transverse, faute de quoi chaque application finit pilotée indépendamment de la chaîne de valeur qu’elle sert. Une à deux fois par an, une revue de trajectoire remet les hypothèses à plat : sont-elles toujours valables, les projets produisent-ils les bénéfices attendus, de nouveaux risques sont-ils apparus ?

La mesure de la valeur doit couvrir cinq familles d’indicateurs : performance industrielle, performance Supply Chain, performance du SI, risques et adoption. C’est la dernière qui est la plus souvent oubliée, alors qu’elle conditionne toutes les autres : un ERP peu utilisé, des processus qui ne basculent pas ou des données mal saisies annulent les bénéfices attendus.

Les erreurs que nous voyons le plus souvent

Deux d’entre elles méritent un commentaire, parce qu’elles sont les plus fréquentes et les plus coûteuses. La première est de cartographier à l’excès : des mois passés à documenter chaque interface produisent un inventaire impeccable et aucune décision. Le niveau de détail doit être proportionné aux arbitrages à rendre. La seconde est de confondre la cible et la roadmap : une architecture cible ambitieuse est légitime, à condition d’assumer qu’il faudra plusieurs années et plusieurs étapes intermédiaires pour l’atteindre.

Notre approche chez Kheops Conseil

Nous ne venons pas avec une solution prédéfinie. Notre rôle est d’aider la direction générale, la direction industrielle et la DSI à construire ensemble une trajectoire qu’elles comprennent, qu’elles peuvent financer et que les sites peuvent absorber. Cela passe par une démarche de co-construction, des ateliers avec les sites dès le diagnostic, et des livrables conçus pour décider plutôt que pour documenter.

FAQ sur le schéma directeur du SI industriel

En conclusion

Un schéma directeur du SI industriel réussi n’est ni une photographie exhaustive du SI, ni un plan informatique figé. C’est un cadre de décision qui relie la stratégie industrielle aux capabilités à développer, aux applications qui les portent et aux investissements qui les financent. Sa force tient à sa double nature : une vision cible lisible d’un côté, une trajectoire réaliste et gouvernée de l’autre.

Pour les DSI comme pour les directions industrielles, l’enjeu n’est donc pas de « faire un schéma directeur », mais d’en faire un outil qui tient face à la réalité du terrain. Co-construit, gouverné et mis à jour, il devient l’un des leviers les plus puissants de performance et de résilience dont dispose une entreprise industrielle.