La transformation data-centric des EPC : pourquoi la technologie ne suffit pas (et ce qu'il faut faire pour qu'elle tienne ses promesses).

Samy BENOUDIZ
20 mai
11 min de lecture

Une lecture critique et constructive du white paper d'AVEVA "Embracing innovation: "Four ways EPCs can overcome key challenges to increase profitability"

Introduction — Un constat dérangeant au milieu d'un excellent document

AVEVA, l'un des leaders mondiaux des plateformes d'ingénierie pour les industries de procédés et les infrastructures, vient de publier un White Paper remarquable sur les quatre grands défis des EPC (Engineering, Procurement and Construction) : conquérir de nouveaux marchés, gérer des projets de plus en plus complexes, tenir les marges, et remettre des offres compétitives. La thèse centrale du document est claire : pour relever ces défis, les EPC doivent adopter une approche data-centric de leurs projets.

Le document est solide, documenté, et appuyé sur des cas clients convaincants. Les bénéfices mesurés sont réels : six semaines économisées sur chaque liste d'ingénierie ici, 16 % sous budget là, 29 % de « rework » en moins ailleurs, jusqu'à 60 % de gains de délai dans certains cas.

Et pourtant, au détour d'une note de bas de page, AVEVA cite une étude d'Accenture Industry X « Building More Value With Capital Projects" (2020), fondée sur une enquête auprès de 710 dirigeants d'owner-operators et d'EPC dans 20 pays, laquelle contient selon nous le vrai sujet : seul un EPC sur trois ayant investi dans des outils digitaux parvient à améliorer ses indicateurs clés. Autrement dit, deux dirigeants sur trois ont dépensé sans récolter.

Cette statistique mérite qu'on s'y arrête. Si la technologie est aussi mûre que le démontrent les cas clients, et si les bénéfices potentiels sont aussi importants, pourquoi deux dirigeants sur trois échouent-ils à les concrétiser ? La réponse n'est pas dans le White Paper. Elle est ailleurs, et c'est là que se joue la vraie réussite des transformations d'ingénierie aujourd'hui.

Accenture elle-même identifie deux causes principales : "un échec stratégique à construire le bon environnement opérationnel et les bonnes incitations pour créer une culture data-centric" et "une incapacité à opérationnaliser la donnée et la technologie pour des décisions plus efficaces". Autrement dit, ni le problème ni la solution ne sont technologiques.

1. La transformation data-centric, de quoi parle-t-on réellement ?

Avant d'entrer dans le débat, posons une définition claire, car ici le changement d’approche est en soi révolutionnaire dans l’entreprise qui s’y engage.

Une rupture de paradigme, pas un simple changement d'outil

Dans l'ingénierie traditionnelle, le document est le livrable clé. On produit des plans, des schémas P&ID, des notes de calcul, des spécifications, des listes d'équipements, des dossiers de commissioning. Ces documents produits par des équipes différentes se succèdent avec de très nombreuses versions.

Les données techniques existent à l'intérieur de ces documents, et chaque discipline (process, mécanique, électricité, instrumentation, génie civil) tient ses propres documents avec ses propres outils, générant parfois de sérieuses divergences de tous ordres entre documents.

Dans une approche data-centric, on inverse la logique, et c’est la donnée qui devient l'actif principal et non plus les documents produits.

Les documents ne sont plus que des vues générées à partir d'un référentiel unique. Une vanne, un équipement, une ligne process n'existent qu'une seule fois dans la base avec l'ensemble de leurs attributs (spécification, fournisseur, position 3D, statut, historique de modification). Le P&ID, le modèle 3D, la liste d'achats, le dossier de commissioning, le manuel de maintenance livré au client ne sont que des projections cohérentes et structurées de ces données.

Cette inversion de logique produit quatre bénéfices concrets et mesurables que les cas du White Paper documentent bien :

La fin du « rework » lié aux incohérences inter-disciplines. Pour dire les choses simplement, lorsqu'une vanne est modifiée en amont, la modification se propage automatiquement à toutes les vues, donc tous les documents. Plus de risque qu'une spécification ait été mise à jour dans le P&ID mais pas dans la liste d'achats. C'est de là que viendraient les 29 % de « rework » évités chez deux clients cités par Aveva.
Un « handover » fluide vers l'exploitant. Le client final ne reçoit plus une montagne de documents à reconstituer pour exploiter son installation, mais un jumeau numérique (digital twin) immédiatement exploitable. Cela transforme la relation EPC– « owner-operator » d'une logique transactionnelle vers un véritable partenariat de long terme. En réalité les « handovers » sont facilités entre toutes les parties prenantes du projet et ce à chaque étape.
Une traçabilité des décisions. Chaque modification, chaque validation, chaque « change order » est tracé dans la donnée. Précieux pour les audits, indispensable pour les contentieux, structurant pour le retour d'expérience. Avec un tel outil, les stratégies de claims sont plus favorables à celui qui possède une telle traçabilité, qu’aux autres parties.
Et surtout : le terrain prêt pour l'IA. C'est le point que le White Paper ne dit pas assez fort. Aucune intelligence artificielle appliquée à l'ingénierie ou à la gestion de projet ne fonctionne sans donnée structurée et fiable.

Sans data-centricity, l’IA ne peut pas être performante. Avec l’IA, elle devient un véritable copilote. Elle permet la prédiction des dérives planning rattachées aux mailles WBS, la détection précoce des risques contractuels, l’optimisation des séquences de construction et l’analyse automatique de la productivité chantier parmi d’autres.

La data-centricity n'est pas une fin en soi : c'est la condition préalable à la prochaine grande mutation de notre métier, celle qui associe ingénierie, WBS et IA.

A noter que le grand oublié du discours data-centric est le « contrat », ou plutôt les contrats, avec les engagements de résultats, les volets financiers, le planning et le QSE parmi d’autres.

Dans un grand chantier le nombre de contrats est extrêmement élevé entre parties prenantes. A ces contrats s’ajoutent ceux relatifs à la sous-traitance majeure, les commandes fournisseurs et tous les contrats annexes (assurances, garanties, financement, foncier, raccordements, autorisations). Tous ces documents contiennent des engagements interdépendants : délais, prix, conditions de paiement, transferts de risque, clauses de force majeure, mécanismes de variation, procédures de notification, juridiction compétente, pénalités de retard et garanties de performance.

Les informations contenues dans ces documents ne sont pas réellement contenues ni prises en compte par ces outils. L’interface humaine, avec tout ce qu’elle comporte de subjectivité, est indispensable.

2. Les éditeurs ont raison sur la technologie, et leur travail est remarquable

Il faut rendre justice aux éditeurs qui poussent cette mutation depuis vingt ans. AVEVA, avec sa plateforme d'ingénierie unifiée enrichie depuis 2021 par le PI System d'OSIsoft. Dassault Systèmes, avec 3DEXPERIENCE et son concept de « jumeau numérique » ». Hexagon, avec sa vision Smart Digital Reality. Bentley Systems, avec la plateforme iTwin dédiée aux infrastructures. Chacun, à sa manière, défend la même conviction : la donnée d'ingénierie est un actif stratégique, pas un sous-produit des projets.

Leur travail est techniquement remarquable. Les plateformes existent, elles sont matures, elles s'intègrent aux outils CAO du marché, elles gèrent le cloud, elles savent dialoguer avec les systèmes des « owner-operators ». Les cas clients du White Paper ne sont pas des promesses, ce sont des résultats vérifiés.

Sur le plan technologique, le problème est résolu. C'est sur un autre plan que se joue l'échec des deux tiers.

3. Pourquoi deux EPC sur trois n'obtiennent-ils pas le retour attendu ?

Le White Paper d'AVEVA contient une promesse qui résume parfaitement l'angle mort du discours commercial :

"By taking a data-centric approach, EPCs can integrate digital tools with existing processes to increase workforce efficiency, scale effectively, simplify complex simulations, and deepen trusted partnerships with clients without disrupting today's operations."

Sans perturber les opérations en cours. La formule est séduisante, et il faut comprendre pourquoi il convient de la relativiser au niveau de l’entreprise.

Vraie au niveau de l'ingénierie

Au périmètre d'un bureau d'études ou d’une ingénierie, la promesse est défendable. Centraliser les données techniques, unifier les bibliothèques de composants, intégrer les modèles 3D et les P&ID dans une plateforme commune, tout cela peut effectivement se déployer par paliers, sans bloquer les projets en cours.

A relativiser au niveau de l'entreprise

Dès qu'on quitte l'ingénierie pour aborder les autres dimensions d’entreprise on change radicalement de périmètre. On parle alors de :

Refondre les contrats pour intégrer des exigences modernes de livrables data structurés, qui varient fortement selon les secteurs : standards internationaux comme CFIHOS et ISO 15926 dans le pétrole-gaz, KKS dans la production électrique, écosystème BIM/ISO 19650 dans les infrastructures de transport, et référentiels propres à chaque grand maître d'ouvrage dans l'eau et le nucléaire
Transformer la chaîne achats pour intégrer les fournisseurs au référentiel de données ;
Basculer dans le cloud, ce qui touche confidentiellement des savoir-faire, mais aussi à la sécurité et à la souveraineté si l’on parle d’actifs comme les usines d’eau, les centrales nucléaires et énergétiques ou encoure les data centers. Il faut ici intégrer les volets conformité (RGPD, ITAR, exigences souveraines), les modèles économiques (CAPEX vers OPEX), et les compétences IT internes.
Changer les gestes métier des ingénieurs, qui ne produisent plus un document mais alimentent une base, un défi majeur de formation et d’accompagnement du changement. ;
Redéfinir les indicateurs de performance des équipes projet, qui ne pilotent plus des livrables mais un référentiel vivant ;
Renégocier les relations partenaires au sein des groupements, Joint-venture et Société de Projet (SPV) qui réalisent les projets, chacun avec son propre niveau de maturité digitale.

Aucun de ces volets ne peut se faire "sans perturbation". Chaque volet touche des contrats, des organisations, des habitudes, des compétences. Et c'est précisément à cet endroit, dans cet écart entre la transformation des outils et la transformation de l'entreprise, que se loge l'échec des deux tiers.

Le diagnostic

Les EPC qui rencontrent des difficultés dans cette démarche ou qui échouent ne se trompent pas d'outil. Ils se trompent de niveau d'effort. Ils achètent une technologie en pensant qu'elle suffira à elle seule à produire la transformation et ce n’est bien sûr jamais le cas. Ils découvrent trop tard que la conduite du changement n'est pas une étape optionnelle ni un coût marginal du projet IT, c’est le cœur du projet lui-même.

4. Les quatre piliers d'une transformation data-centric réussie

C'est ici que l'expérience de terrain devient indispensable. Avoir dirigé des entreprises d'ingénierie ou de construction, piloté des projets publics et privés, médié des différends entre partenaires de groupements : autant de vécus qui enseignent ce que les manuels ne disent pas. Voici les quatre piliers qui, à mes yeux, distinguent les transformations qui tiennent leurs promesses de celles qui s'enlisent.

Pilier 1. Une feuille de route jalonnée, pas un big bang

Une transformation data-centric réussie n'est jamais une bascule unique. Elle se construit par paliers mesurables, chacun produisant un bénéfice tangible avant de passer au suivant. Le pilote sur un projet isolé, puis l'extension à une discipline, puis à une BU, puis au groupe. Chaque jalon doit être :

Borné dans le temps (3 à 6 mois pour un palier, pas davantage) ;
Mesurable (un indicateur de succès clair, défini à l'avance) ;
Réversible si nécessaire (pas de passage forcé au palier suivant si le précédent n'a pas tenu).

Cette logique de paliers est exactement celle qui structure les « Executive Roadmaps » dans les transformations complexes : on ne sort pas d'une situation difficile d'un seul mouvement, on construit un chemin.

Pilier 2. Des feuilles de route cohérentes entre toutes les parties prenantes

C'est le pilier le plus souvent négligé. Une transformation data-centric ne concerne pas que l'EPC. Elle implique :

La direction générale et les investisseurs, qui attendent un ROI sur l'investissement digital ;
Les équipes d'ingénierie, dont les gestes métier changent ;
Les partenaires au sein du groupement, JV ou SPV, qui doivent partager le même référentiel ;
Les fournisseurs et sous-traitants, qui doivent alimenter ce référentiel ;
Les clients owner-operators, qui attendent un livrable data exploitable ;
Les assureurs et financeurs, qui suivent les risques techniques et contractuels.

Chacune de ces parties prenantes a sa propre feuille de route, ses propres intérêts, ses propres contraintes. Toutes les feuilles de route doivent rester cohérentes entre elles, sans pour autant être identiques. C'est l'un des points les plus délicats du pilotage d'une transformation : préserver l'alignement stratégique tout en respectant les spécificités de chaque acteur.

Lorsque cet alignement se perd, les transformations dégénèrent en discordes entre partenaires, en dérives contractuelles, en claims, voire en contentieux. C'est précisément le moment où la médiation et le contract management deviennent indispensables, non plus comme remède, mais comme outils de prévention intégrés à la conduite du changement.

Pilier 3 . Une communication continue qui explique le pourquoi avant le comment

Aucune équipe d'ingénierie n'adopte durablement un outil qu'on lui impose. Les ingénieurs, les dessinateurs, les chefs de projet ont des décennies d'expertise dans leurs méthodes actuelles. Leur demander de changer sans expliquer le sens du changement, c'est garantir une adoption superficielle qui n'engendre aucun gain réel.

Une transformation data-centric exige donc une communication soutenue et différenciée :

Au COMEX, sur le ROI stratégique et le positionnement concurrentiel ;
Aux managers de projet, sur les nouveaux modes de pilotage et de reporting ;
Aux ingénieurs et techniciens, sur ce qui change dans leur métier et ce que cela leur apporte ;
Aux partenaires et clients, sur les nouveaux livrables et les nouveaux modes de collaboration et ce que cela implique de changements à leur niveau.

Sans cette communication, le meilleur logiciel ne réussit pas son adoption au sein de l’entreprise et l'investissement se solde par un échec.

Pilier 4. Des KPI de transformation, distincts des KPI projet

Les EPC qui réussissent ne se contentent pas de mesurer le délai, le coût et la qualité de leurs projets. Ils mesurent aussi, en parallèle, la maturité de leur transformation data-centric :

Cinétique de déploiement et adoption des outils par les équipes (taux d'utilisation effective, et non taux de licences déployées) ;
Taux de données structurées dans le référentiel par rapport au total des données projet
Taux de réutilisation des composants de la bibliothèque commune ;
Qualité du référentiel (taux d'incohérences détectées, temps moyen de correction) ;
Satisfaction des clients owner-operators sur les livrables data.

Sans ces indicateurs spécifiques, on ne sait pas si la transformation avance et on se cantonne au suivi de l’avancement du projet, sans détecter à temps la non-adoption de la nouvelle méthode par les équipes.

5. Data-centricity, WBS et IA : ce qui se joue dans les cinq prochaines années

Pourquoi est-il urgent de réussir cette transformation maintenant ? Parce qu'elle n'est pas une fin en soi. Elle est la condition d'accès à la prochaine vague : celle de l'intelligence artificielle appliquée à l'ingénierie et à la gestion de projet.

L'IA appliquée aux projets complexes promet des bénéfices considérables. Sous le mot "IA", il faut entendre une réalité multiple : modèles prédictifs sur les données planning et coût, traitement du langage naturel sur les contrats et correspondances, simulation et optimisation des séquences de construction. Ces approches s'incarnent indifféremment dans des modules embarqués des plateformes du marché, dans des produits spécialisés (juridiques, chantier, contractuels), ou dans des développements internes outillés par les API IA grand public. Nous en citerons quelques cas d'usage :

Prédiction des dérives planning à partir des données chantier rattachées au WBS,

Détection précoce des risques contractuels par analyse automatique des correspondances et des claims,
Mais aussi analyse prédictive des litiges potentiels au sein des groupements.
Optimisation des séquences de construction par simulation,
Suivi de productivité en temps réel sur les chantiers,

Tout cela est techniquement à portée de main, à condition de disposer d'une donnée structurée, fiable et reliée à la maille WBS du projet, et d'avoir choisi le bon niveau d'outillage entre plateforme intégrée, produit spécialisé et développement interne.

Les EPC qui auront réussi leur transformation data-centric dans les trois prochaines années seront en position de capter ces gains. Ceux qui auront échoué , les fameux deux tiers de l'étude Accenture, se retrouveront avec des outils sous-utilisés, des données fragmentées, et l'incapacité de bénéficier de l'IA autrement que par des expérimentations isolées sans impact systémique. L'écart entre les deux groupes va se creuser, et il deviendra de plus en plus difficile à combler à mesure que les outils IA gagneront en maturité

Conclusion — La technologie est une condition nécessaire, pas suffisante

Le white paper d'AVEVA a raison sur le fond. Les défis qu'il décrit sont réels. La solution qu'il propose, l'approche data-centric, est la bonne. Les cas clients qu'il cite démontrent que les bénéfices sont au rendez-vous quand la transformation est réussie.

Mais le document s'arrête là où commence le volet le plus difficile. Acheter un logiciel, même excellent, ne fait pas une transformation. Conduire une transformation, c'est aligner les parties prenantes, jalonner le chemin, mesurer l'avancement, communiquer sans relâche, prévenir les conflits entre partenaires, et garder le cap sur des KPI spécifiques qui disent si la mutation prend racine ou si elle reste de surface.

Si deux EPC sur trois échouent malgré la qualité des outils disponibles, ce n'est pas un échec de la technologie. C'est un échec de la méthode. Et c'est une bonne nouvelle, parce que la méthode, contrairement à la technologie, ne s'achète pas elle se construit, projet après projet, avec ceux qui ont l'expérience opérationnelle pour la porter.

Les dirigeants d'EPC qui s'engagent aujourd'hui dans cette transformation ont une opportunité historique. À condition de ne pas se tromper sur le combat à mener.

Vous êtes dirigeant d'une entreprise d'ingénierie, d'EPC ou d'infrastructure et vous engagez une transformation data-centric ? Vous voulez sécuriser l'alignement de vos parties prenantes et la trajectoire de votre projet ? Contactez-moi

Au sujet de l’auteur : Samy Benoudiz est ingénieur agronome. Il a dirigé des sociétés d'ingénierie et d'infrastructures dans l'eau et l'énergie, notamment comme directeur général de Tractebel France-Afrique-Chine (Engie) et vice-président exécutif de Degrémont Industry (Suez). Ancien maire d'Aigremont et ancien membre du CPO (Conseil des prélèvements obligatoires), il est aujourd'hui consultant indépendant (Kanda Consulting). Il accompagne des projets complexes en infrastructures et industries pour anticiper les points de friction et réduire les risques de ralentissement ou de litiges avec les clients, par de la médiation de projet.