Dossier permanent · Industrie & QHSE
Logiciel VGP : ce que le SaaS a changé dans la gestion des vérifications générales périodiques
Derrière l'acronyme VGP se cache une brique logicielle discrète mais critique : elle porte le référentiel des équipements, l'échéancier réglementaire et la preuve opposable des contrôles. Le passage au SaaS en a modifié la conception autant que la gouvernance.
Publié le 17 août 2026
Une brique métier née du tableur
La vérification générale périodique — VGP — désigne le contrôle obligatoire des équipements de travail : appareils de levage, engins de chantier, portes et portails automatiques, équipements sous pression, systèmes de protection collective. L'obligation est ancienne ; son outillage informatique, lui, est resté longtemps rudimentaire. Pendant deux décennies, l'échéancier de contrôle a vécu dans un classeur de tableur partagé, alimenté à la main après chaque passage de vérificateur.
Ce mode de gestion tient tant que le parc est petit et mono-site. Il casse dès qu'un groupe exploite plusieurs centaines d'équipements répartis sur des dizaines d'établissements, avec des prestataires de contrôle différents selon les régions. Trois défaillances reviennent systématiquement : l'échéance manquée faute d'alerte, le rapport introuvable au moment de l'inspection, et la divergence entre l'inventaire comptable et le parc réellement exploité.
C'est cette accumulation de dettes documentaires, plus que la réglementation elle-même, qui a créé un marché logiciel spécifique. Le référentiel réglementaire et sectoriel est détaillé sur controle-reglementaire.fr, ressource utile pour cadrer le périmètre des contrôles avant d'aborder l'outillage.
Le modèle de données : l'équipement, pas le document
La différence structurante entre un classeur numérique et un logiciel VGP tient au pivot du modèle de données. Dans le premier, l'objet central est le rapport de contrôle : un fichier, une date, un nom de prestataire. Dans le second, l'objet central est l'équipement, doté d'une identité stable qui survit aux mutations, aux locations et aux changements de site.
Cette inversion a des conséquences directes. Un équipement identifié porte son historique complet : mises en service, contrôles successifs, réserves émises, levées de réserve, interventions correctives. Un rapport isolé ne porte qu'un instantané. Les outils sérieux exposent d'ailleurs une clé d'identification physique — plaque, code-barres, étiquette QR ou puce sans contact — pour relier le monde physique à l'enregistrement logiciel sans dépendre d'une saisie manuelle du numéro de série.
- Identité d'équipement stable, indépendante du site d'affectation.
- Typologie réglementaire portant la périodicité applicable.
- Chaîne réserve → action corrective → levée, horodatée.
- Rattachement au tiers vérificateur et à son habilitation.
- Historique conservé au-delà de la durée d'exploitation.
L'échéancier, moteur réel du produit
Le cœur fonctionnel d'un logiciel de contrôle réglementaire n'est ni le formulaire ni le rapport PDF : c'est le calculateur d'échéances. Il dérive une date de prochaine vérification à partir du type d'équipement, de sa date de mise en service, de son intensité d'usage et, parfois, d'un régime dérogatoire propre à l'établissement. Un moteur mal conçu produit soit un bruit d'alertes que les exploitants finissent par ignorer, soit des silences qui coûtent cher lors d'un contrôle de l'inspection du travail.
Les implémentations robustes séparent nettement la règle réglementaire — périodicité légale — de la règle interne — marge de sécurité, fenêtre de planification, gel pendant un arrêt technique. Cette séparation évite le piège classique : coder la politique interne d'un client dans le moteur réglementaire, puis ne plus pouvoir mettre à jour ce dernier quand un texte évolue.
SaaS multi-sites : ce que le mode hébergé a réellement apporté
Le passage au SaaS n'a pas seulement changé le mode de facturation. Il a rendu possible une gouvernance à deux étages qui n'existait pas dans les installations locales : une direction technique groupe consolide l'état de conformité de l'ensemble des établissements, pendant que chaque site conserve la main sur son parc et sa planification. Le même jeu de données sert le pilotage central et l'exploitation locale, sans consolidation manuelle mensuelle.
Ce modèle impose en contrepartie des exigences que les acheteurs IT connaissent bien et que les acheteurs QHSE découvrent souvent : cloisonnement strict des données par établissement, gestion fine des rôles — lecture, saisie terrain, validation, administration —, journalisation des accès, réversibilité contractuelle et export intégral des historiques. Un dossier de conformité qui ne peut pas être exporté n'appartient pas vraiment à l'exploitant.
La question de la localisation d'hébergement se pose aussi, moins pour des raisons de données personnelles — les rapports en contiennent peu — que pour la disponibilité opérationnelle. Un site industriel bloqué faute d'accès à son registre de sécurité au moment d'une visite n'a que faire d'un engagement de service exprimé en pourcentage annuel.
Intégration : GMAO, achats et systèmes de gestion
Un logiciel VGP isolé recrée une base d'équipements parallèle à celle de la GMAO, et l'écart entre les deux se creuse en quelques trimestres. Les déploiements qui tiennent dans la durée traitent la question d'intégration dès le cadrage, en désignant un système maître pour le référentiel d'équipements — le plus souvent la GMAO — et en laissant à l'outil de contrôle la responsabilité des échéances et des preuves.
Les points d'échange récurrents sont peu nombreux mais structurants : création et retrait d'équipement, statut de conformité renvoyé vers la GMAO pour bloquer une remise en service, génération d'une demande d'achat quand une réserve impose un remplacement de pièce. Une interface applicative documentée, avec authentification par jeton et pagination des historiques, suffit à couvrir ces cas ; les intégrations par dépôt de fichiers plats survivent rarement au premier changement de format.
Les trois plans de ce dossier
Cette page traite l'architecture et la gouvernance. Deux analyses complémentaires prolongent le sujet sur des plans différents : l'exécution sur le terrain, avec la contrainte du hors-ligne et de la preuve, et l'exploitation des données de contrôle dans un système de management QHSE, y compris pour des structures qui n'ont ni service informatique ni responsable sécurité à temps plein.