Lors du déploiement d’une plateforme HSE, les responsabilités sont généralement assez bien définies, et l’on s’interroge rarement sur la gouvernance des plateformes HSE. Il existe une équipe projet, des responsables fonctionnels, des utilisateurs clés, l’IT, des administrateurs, des consultants ou intégrateurs et, si nécessaire, l’éditeur de la solution. L’équipe discute, valide et suit les décisions, car tous partagent un objectif commun : mettre la plateforme en service.
Cependant, après la mise en production, cette structure peut disparaître rapidement. L’équipe projet retourne à ses fonctions habituelles, les réunions s’espacent et l’organisation commence à traiter la plateforme comme une partie de l’exploitation. C’est précisément à ce moment qu’apparaît l’une des questions les plus importantes pour la pérennité de la solution : qui est chargé de garantir que la plateforme reste correcte, cohérente et alignée sur l’organisation ?
Le propriétaire de la plateforme HSE peut difficilement être une seule personne ou un seul service. En effet, une plateforme HSE réunit technologie, processus, données, exigences, utilisateurs et décisions opérationnelles. L’IT peut être responsable de la sécurité, de l’authentification ou des intégrations, mais ne doit pas définir seule les critères de conformité. Le HSE connaît les processus et les risques, mais n’est pas forcément responsable de l’administration technique. Les Opérations connaissent la réalité du terrain, mais ne doivent pas modifier unilatéralement les standards de l’entreprise. L’administrateur sait configurer, mais cela ne signifie pas qu’il doive décider seul de ce que l’organisation veut contrôler.
C’est pourquoi il convient d’envisager l’ownership de façon plus large. La plateforme HSE n’a pas seulement besoin d’un « propriétaire ». Elle a besoin d’un modèle clair de responsabilités.
Gouvernance des plateformes HSE : La responsabilité fonctionnelle n’est pas l’administration technique
L’une des décisions les plus importantes après le déploiement consiste à séparer clairement qui décide de ce qui doit se passer et qui exécute la configuration correspondante.
Imaginez qu’une organisation souhaite ajouter une nouvelle exigence documentaire à une fonction donnée. Techniquement, la modification peut être relativement simple. Un administrateur peut créer l’exigence, définir sa validité, l’associer à un profil et la mettre en production. Pourtant, la décision a des conséquences qui dépassent la configuration. Par exemple, elle peut modifier le statut d’intervenants déjà actifs, générer de nouveaux points en suspens ou conditionner de futures mobilisations.
Par conséquent, la personne qui a autorité sur le processus doit trancher la question fonctionnelle. L’administrateur, quant à lui, doit garantir que la plateforme reflète correctement cette décision.
Cette distinction s’applique à bien d’autres cas : modifier un workflow, créer un nouveau statut, changer une permission, retirer une approbation ou introduire une nouvelle classification. Autrement dit, disposer des droits pour effectuer une modification ne donne pas automatiquement l’autorité de décider que cette modification doit exister.
Lorsque cette séparation n’est pas claire, deux risques apparaissent. D’un côté, chaque changement exige un processus trop bureaucratique et la plateforme perd en agilité. De l’autre, quelqu’un effectue sans cesse de petites modifications sans évaluer leur impact et, au bout d’un certain temps, la solution accumule exceptions et incohérences.
C’est pourquoi une gouvernance efficace doit trouver l’équilibre entre ces deux modèles. L’équipe peut réaliser en autonomie les modifications simples et à faible impact. En revanche, les changements qui touchent les processus, la conformité, la sécurité ou plusieurs domaines doivent suivre un niveau de validation proportionné à leur impact.
Les données ont aussi besoin d’un propriétaire dans la plateforme HSE
Par ailleurs, la responsabilité de la plateforme ne s’arrête pas aux workflows et aux configurations. Les données ont, elles aussi, besoin d’un modèle clair de responsabilité.
Qui décide de la manière d’identifier une entreprise ? À qui revient-il d’éviter les doublons ? Qui contrôle la nomenclature des équipements ? Et qui peut créer une nouvelle catégorie documentaire ? Qui décide si un champ donné reste nécessaire ? Qui arbitre lorsque deux systèmes contiennent des informations contradictoires ?
Ces questions deviennent de plus en plus importantes à mesure que la plateforme intègre différents processus. Une entreprise peut être liée à des intervenants, des équipements, des contrats, de la documentation et des projets. Un intervenant peut, quant à lui, être associé à des formations, des compétences, des activités et des exigences. Ainsi, une erreur dans une donnée de base peut se propager à différents domaines de la plateforme.
Ainsi, sans ownership, la tendance naturelle est la dégradation progressive de l’information. De nouvelles appellations apparaissent pour une même réalité, ainsi que des catégories en double, des statuts similaires et des exceptions locales. Prise isolément, chaque décision peut sembler anodine ; ensemble, elles réduisent la qualité des tableaux de bord, compliquent les intégrations et augmentent l’effort de maintenance.
La gouvernance des données doit définir qui fixe les critères de chaque ensemble d’informations et qui est chargé d’en assurer la cohérence. Toutefois, cela ne signifie pas centraliser toute la maintenance sur une seule personne. Il s’agit plutôt de garantir qu’une personne a l’autorité pour trancher en cas de doute ou de conflit.
Cette responsabilité doit se maintenir tout au long du cycle de vie de la plateforme. La migration initiale peut créer une base saine, mais seul un modèle de gouvernance continu permet de préserver cette qualité.
Client, intégrateur et éditeur ont des responsabilités différentes
En outre, il est important de distinguer clairement les rôles de ceux qui utilisent, déploient et développent la technologie.
Le client doit rester propriétaire des processus et des décisions métier. C’est l’organisation qui connaît ses risques, ses exigences, sa structure et ses priorités. De son côté, l’intégrateur traduit ces besoins dans la plateforme, accompagne le paramétrage, conseille sur la conception fonctionnelle et aide à évaluer les impacts. Enfin, l’éditeur est responsable de la technologie, de l’évolution du produit et de la correction des problèmes propres au logiciel.
Cette distinction est importante, car toutes les demandes ne doivent pas remonter au même niveau.
L’équipe interne ou le support fonctionnel peut traiter une question d’utilisation. De même, l’administrateur ou l’intégrateur peut prendre en charge une modification de configuration. Une décision sur une exigence doit appartenir au client. Enfin, une défaillance technique du produit peut nécessiter l’intervention de l’éditeur.
Lorsque ces niveaux ne sont pas définis, les demandes circulent entre les équipes, le délai de réponse s’allonge et les utilisateurs ne savent plus qui doit traiter chaque situation.
Un modèle mature cherche à résoudre chaque question au bon niveau et à ne remonter que lorsque c’est nécessaire. Cela réduit la dépendance et renforce l’autonomie, sans supprimer l’accès à une expertise spécialisée.
Il protège aussi l’organisation contre un risque fréquent : faire de l’administrateur interne la personne responsable de tout. Un utilisateur expérimenté peut connaître la plateforme en profondeur. Toutefois, il ne doit pas concentrer seul la configuration, le support, la définition fonctionnelle, la qualité des données et les décisions sur tous les processus. Cette dépendance crée une vulnérabilité opérationnelle. Elle peut aussi conduire à des décisions importantes prises de manière informelle, simplement parce qu’une personne connaît mieux le système.
La gouvernance doit se poursuivre après le déploiement
Pendant la phase projet, la discipline est généralement plus forte. Les équipes discutent, testent et valident les modifications. Après la mise en production, une logique plus réactive peut s’installer : quelqu’un demande un changement, l’administrateur le réalise et le processus continue.
C’est ainsi que de nombreuses plateformes commencent lentement à s’éloigner du modèle défini au départ.
Un nouveau projet exige une exception. Une équipe demande un autre statut. Un client réclame un document spécifique. Un utilisateur veut une vue différente. Pourtant, aucune de ces décisions n’est forcément problématique. Le risque apparaît lorsqu’on traite chaque demande isolément, sans vérifier si le besoin est local, temporaire ou assez important pour modifier le modèle global.
Par conséquent, la gouvernance ne doit pas s’arrêter avec la fin du projet de déploiement. Elle doit accompagner l’évolution de la plateforme.
Il n’est cependant pas nécessaire de créer des structures lourdes. Dans de nombreuses organisations, il suffit de définir des responsables, des critères de modification, un registre des changements importants et des revues périodiques. L’essentiel est que l’évolution soit intentionnelle.
Il faut également un certain niveau de traçabilité. Lorsqu’une règle importante change, il devrait être possible de comprendre ce qui a changé, pourquoi et qui a validé la décision. Sans ce contexte, la plateforme finit par dépendre de la mémoire des personnes, et cette mémoire se perd lors des changements d’équipe.
La gouvernance doit garantir la continuité.
Le véritable propriétaire de la plateforme HSE est un modèle de responsabilités
Se demander « qui est le propriétaire de la plateforme HSE ? » est utile, car cela oblige l’organisation à identifier des responsabilités qui restent souvent implicites.
L’IT peut être responsable de l’architecture et de la sécurité. Le HSE peut être propriétaire des processus fonctionnels. Les Opérations peuvent être responsables de l’exécution sur le terrain. La Gestion documentaire peut contrôler certaines exigences et certains critères. Les administrateurs peuvent gérer la configuration. L’intégrateur peut accompagner l’évolution et l’optimisation. Enfin, l’éditeur garantit la technologie.
Cependant, aucune de ces responsabilités, prise isolément, ne suffit.
En réalité, la valeur réside dans la manière dont elles s’articulent.
Une plateforme HSE est un système vivant. L’organisation change, les exigences évoluent, de nouveaux utilisateurs arrivent et de nouveaux besoins apparaissent. Sans gouvernance, cette évolution se fait de manière fragmentée. Avec une gouvernance, en revanche, la plateforme peut s’adapter tout en préservant la cohérence, la qualité des données et l’alignement avec l’exploitation.
Les questions essentielles sont simples :
Qui décide ? Qui configure ? Et qui maintient les données ? Qui assure le support ? Qui approuve les modifications critiques ? Et qui suit l’utilisation ? Enfin, qui garantit que la plateforme reste alignée sur les objectifs de l’organisation ?
Répondre à ces questions est aussi important que choisir la technologie.
Car, après la mise en production, la plateforme n’est plus seulement un projet.
Elle devient une infrastructure opérationnelle.
Et une infrastructure de ce type a besoin de responsabilités claires, de décisions structurées et d’un ownership continu pour rester utile dans la durée.
Pour aller plus loin : Plateforme HSE et digitalisation HSE : Guide complet.
À lire aussi : Plus la plateforme HSE est configurable, plus la gouvernance doit être forte et Comment mesurer si une plateforme HSE est réellement adoptée.
Pour en savoir plus sur les normes internationales de management, consultez le site de l’Organisation internationale de normalisation (ISO).