Développer une solution QHSE en interne : 5 idées reçues à questionner avant de décider

Vous cherchez à simplifier un processus QHSE devenu trop lourd à gérer. L’idée de développer un outil en interne peut alors sembler évidente : une solution adaptée à votre organisation, maîtrisée par votre DSI et sans nouvel abonnement logiciel. Sur le papier, l’équation paraît avantageuse.

Mais développer l’outil n’est que le début du projet. Il faudra ensuite le déployer, accompagner les utilisateurs, assurer son support, assurer sa maintenance et le faire évoluer au rythme de vos besoins. La question n’est donc pas seulement de savoir si votre DSI peut développer une solution QHSE. Il faut déterminer si cette solution pourra rester simple à utiliser, maintenir et faire évoluer dans la durée.

Avant de vous lancer, voici cinq idées reçues à questionner.

1 - Idée reçue n°1 : développer en interne sera plus rapide

2 - Idée reçue n°2 : une solution sur mesure sera forcément plus simple à utiliser

3 - Idée reçue n°3 : la DSI pourra facilement assurer le suivi

4 - Idée reçue n°4 : l’outil évoluera facilement avec nos besoins

5 - Idée reçue n°5 : la solution interne coûtera moins cher

Idée reçue n°1 : développer en interne sera plus rapide

Un développement interne peut sembler être le chemin le plus direct entre votre besoin et la solution. Vous connaissez vos processus, votre DSI connaît votre système d’information : pourquoi passer par un prestataire externe ? En pratique, le projet commence bien avant la première ligne de code.

Un besoin simple peut vite devenir un projet IT

Au départ, l’objectif paraît souvent limité : digitaliser un accueil sécurité, remplacer un formulaire papier ou mieux structurer un processus de prévention.

Puis les questions apparaissent. Qui pourra créer ou modifier les contenus ? Quels droits attribuer à chaque utilisateur ? Comment gérer différents établissements ? Quelles données conserver ? Quels indicateurs suivre ? Comment traiter les personnes sans poste informatique ? Comment intégrer plusieurs langues ou plusieurs catégories d’intervenants ?

Un processus QHSE relativement simple peut ainsi devenir un véritable projet informatique dès qu’il doit tenir compte de la réalité du terrain.

Développer l’outil n’est que le début 

Avant la mise en production, il faut notamment :

• formaliser les besoins métier ;
• définir les différents cas d’usage ;
• rédiger les spécifications ;
• développer la solution ;
• réaliser les tests ;
• corriger les anomalies ;
• préparer le déploiement ;
• former les administrateurs et utilisateurs.

Les équipes QHSE participent à plusieurs de ces étapes en parallèle de leurs missions quotidiennes de prévention. Le temps nécessaire ne dépend donc pas uniquement de la capacité de développement de la DSI. Il dépend également de la disponibilité des équipes métier et de leur capacité à traduire leurs processus en exigences fonctionnelles précises.

Une solution SaaS spécialisée part d’une logique différente : le socle technologique existe déjà. L’effort porte davantage sur le paramétrage, la contextualisation des parcours et l’intégration de la solution dans l’organisation existante.

Idée reçue n°2 : une solution sur mesure sera forcément plus simple à utiliser

Une solution développée spécifiquement pour votre organisation peut parfaitement couvrir les fonctionnalités demandées. Cela ne garantit pas pour autant qu’elle sera facile à prendre en main par tous les utilisateurs. 

Fonctionnel ne veut pas dire facile à utiliser 

Dans un projet interne, l’objectif prioritaire consiste souvent à répondre au cahier des charges : permettre une action, enregistrer une information, générer un résultat. L’expérience utilisateur peut alors passer au second plan, notamment lorsque les délais ou les ressources sont contraints.

Or, une solution QHSE peut être utilisée par des publics très différents : managers, opérateurs, intérimaires, nouveaux arrivants, prestataires ou entreprises extérieures. Certains l’utiliseront quotidiennement. D’autres seulement quelques fois par an. Plus la prise en main nécessite d’explications, plus le risque est de créer de nouveaux irritants autour d’un processus que vous cherchiez justement à simplifier.

Les frictions d’usage retombent sur les équipes QHSE

Lorsque les parcours sont peu intuitifs, les erreurs augmentent et les demandes d’assistance se multiplient. Les équipes QHSE peuvent alors devoir expliquer le fonctionnement de l’outil, corriger des saisies, relancer les utilisateurs ou maintenir des fichiers parallèles pour compenser certaines limites.

Le projet de digitalisation risque alors de déplacer la complexité au lieu de la réduire. L’ergonomie n’est donc pas uniquement un sujet de confort. Elle conditionne également l’adoption de l’outil, la qualité des données collectées et la capacité des équipes à utiliser réellement la solution sur le terrain.

Idée reçue n°3 : la DSI pourra facilement assurer le suivi

La mise en production est une étape importante. Elle ne marque pas la fin du projet. Une solution utilisée dans les processus QHSE doit rester disponible, compréhensible et maintenable pendant toute sa durée de vie.

Après le déploiement, les priorités changent 

Pendant le développement, une équipe projet est généralement identifiée. Les interlocuteurs connaissent le besoin, les arbitrages réalisés et le fonctionnement de l’outil.

Une fois la solution déployée, ces ressources peuvent être mobilisées sur d’autres projets. Les demandes d’accès, anomalies, changements de configuration et besoins d’évolution doivent alors être intégrés aux autres priorités de la DSI. Un problème considéré comme urgent par une équipe QHSE ne sera pas systématiquement prioritaire à l’échelle du système d’information.

La connaissance technique peut vite se perdre

Une solution interne dépend également des personnes qui la connaissent. Si un développeur change de fonction ou quitte l’entreprise, une partie de la connaissance peut disparaître. Sans documentation suffisamment précise et régulièrement actualisée, chaque correction devient progressivement plus complexe.

Cette problématique est particulièrement importante lorsque l’outil reste en place plusieurs années. Avec une solution spécialisée, le support, la maintenance et les évolutions font partie du fonctionnement du produit. L’objectif est de ne pas faire reposer la continuité de la solution sur quelques personnes identifiées dans votre organisation.

Idée reçue n°4 : l’outil évoluera facilement avec nos besoins

Le besoin exprimé au lancement du projet est rarement définitif. Les processus QHSE évoluent. De nouveaux sites peuvent rejoindre le dispositif. Les publics changent. De nouveaux contenus deviennent nécessaires et les exigences de pilotage se précisent progressivement.

Vos besoins évoluent plus vite que l’outil 

Après avoir digitalisé un premier processus, vous pourrez par exemple vouloir :

• créer de nouveaux parcours selon le profil des utilisateurs ;
• ajouter des questionnaires de compréhension ;
• proposer plusieurs langues ;
• adapter les contenus selon les risques ;
• gérer de nouvelles catégories d’intervenants ;
• consolider les résultats de plusieurs établissements.

Dans une solution interne, chacune de ces demandes doit être évaluée, priorisée, développée et testée. Une modification simple du point de vue QHSE peut nécessiter une intervention technique beaucoup plus importante.

Le multisite change la donne 

Une solution peut fonctionner parfaitement pour un établissement, quelques administrateurs et un nombre limité d’utilisateurs. La situation devient différente lorsque plusieurs sites, populations, langues et contenus doivent cohabiter.

Il faut alors gérer les droits d’administration, les versions locales, la cohérence des contenus, les données consolidées et parfois des processus différents d’un établissement à l’autre. Le même enjeu se retrouve dans la gestion des entreprises extérieures : les intervenants, risques, consignes et exigences peuvent varier selon les sites tout en nécessitant un pilotage cohérent au niveau de l’organisation.

La capacité à passer à l’échelle doit donc être envisagée dès la conception du projet, et non une fois que la solution commence à être déployée.

Idée reçue n°5 : la solution interne coûtera moins cher

L’absence d’abonnement peut donner l’impression qu’un développement interne sera mécaniquement moins coûteux. Mais comparer uniquement le coût de développement au prix d’un logiciel ne permet pas d’évaluer le coût réel de la solution.

Le développement n’est qu’une partie de l’investissement

Il faut également prendre en compte le temps consacré par les équipes QHSE au cadrage, aux ateliers, aux tests, aux corrections, à la formation et au déploiement. Dans la plupart des méthodes de gestion de projet, on applique d’ailleurs une marge de 20 % supplémentaire pour absorber les coûts directs non anticipés au départ.

Puis viennent les coûts liés à la vie de l’outil :

• maintenance ;
• hébergement ;
• sécurité ;
• support ;
• documentation ;
• administration ;
• corrections ;
• évolutions fonctionnelles.

Ces ressources peuvent être réparties entre plusieurs services et apparaître moins clairement qu’un abonnement logiciel. Elles n’en restent pas moins nécessaires au fonctionnement de la solution.

Plus le projet grandit, plus les coûts augmentent

Pour un besoin très limité, stable, utilisé par peu de personnes et sur un seul site, développer ou adapter une solution interne peut être pertinent. Le raisonnement change lorsque le projet doit gérer plusieurs établissements, des populations différentes, de nombreux contenus ou des évolutions fréquentes.

Plus le périmètre augmente, plus l’organisation doit consacrer de ressources au support, à l’administration et à la maintenance. Une solution métier permet alors d’éviter de redévelopper des fonctionnalités déjà disponibles et de concentrer davantage les équipes QHSE sur leur activité de prévention. Sur ce point, nos clients estiment un retour sur investissement qui s’élève jusqu’à 13 fois le montant investi dans leur solution métier.

Ce qu’il faut retenir avant de développer une solution QHSE en interne

Développer une solution QHSE en interne peut répondre à un besoin ponctuel, stable et clairement délimité. Mais plus le projet doit évoluer, gérer des publics différents ou être déployé à grande échelle, plus les questions de maintenance, d’expérience utilisateur, de support et de pilotage deviennent importantes.

Il ne faut donc pas seulement se demander si votre DSI est capable de développer l’outil. Il faut aussi déterminer qui le maintiendra, qui accompagnera les utilisateurs, comment il évoluera et quelles ressources devront être mobilisées pendant toute sa durée de vie. Cela conditionne aussi votre capacité à rester aligné avec des réglementations qui évoluent en permanence.

Votre objectif initial reste de simplifier vos processus QHSE et de renforcer votre capacité à agir sur le terrain. La vraie question est donc la suivante : votre développement interne va-t-il réellement simplifier votre processus, ou simplement déplacer sa complexité ?

Vous souhaitez en savoir plus sur comment une solution métier QHSE peut vous accompagner dans votre stratégie de prévention ?