Dossier de mission03
Outil de suivi réglementaire
Le contrôle de conformité tenait dans des tableurs partagés. Il tient désormais dans une application reliée aux logiciels métier, avec une trace de chaque décision.
- APPLICATION MÉTIER
- FRANCE / MONACO / SUISSE
- RÉFÉRENCE SUR DEMANDE
Ce que le client nous a confié
Une organisation soumise à obligations réglementaires suivait sa conformité dans des tableurs partagés, complétés par plusieurs logiciels métier qui ne se parlaient pas. Chaque contrôle demandait de rassembler à la main des informations dispersées, puis de consigner le résultat ailleurs.
Le risque n’était pas l’erreur isolée : c’était l’absence de trace. En cas de contrôle externe, reconstituer l’historique d’une décision supposait de retrouver la bonne version d’un fichier, puis de faire confiance à sa date de modification.
La direction souhaitait un outil unique, capable de s’appuyer sur les logiciels en place plutôt que de les remplacer, et de produire une preuve exploitable à tout moment.
Le point de départ
Ce que le diagnostic a révélé.
Avant toute proposition technique, nous écrivons l’état réel — y compris ce qui dérange. C’est cette description, validée par les équipes, qui rend la suite vérifiable.
- 01
Conformité suivie dans des tableurs
Plusieurs fichiers partagés, des versions concurrentes, aucune règle de mise à jour ni de verrouillage.
- 02
Logiciels métier cloisonnés
Les référentiels utiles vivaient dans des applications distinctes, sans passerelle ni identifiant commun.
- 03
Ressaisies systématiques
Une même information était saisie deux ou trois fois, avec des écarts possibles entre les sources.
- 04
Historique non opposable
Aucune trace fiable de qui avait validé quoi, ni à quelle date, ni sur quelle base.
- 05
Échéances surveillées de mémoire
Les obligations étaient suivies par courriel et par habitude, sans alerte automatique en cas d’oubli.
- 06
Accès indifférenciés
Le fichier partagé ne distinguait pas les rôles : toute personne disposant du lien pouvait modifier n’importe quelle ligne.
Les contraintes
Ce qui ne pouvait pas être compromis.
- 01
L’outil doit épouser le geste réel
Les équipes de contrôle travaillent vite, souvent sur deux écrans. Toute saisie supplémentaire devait être justifiée par un gain ailleurs.
- 02
Ne pas remplacer les logiciels en place
La mission portait sur une couche de contrôle et de preuve, pas sur un changement de système d’information.
- 03
Une traçabilité opposable
Chaque décision devait être datée, attribuée et conservée, y compris après correction ou annulation.
- 04
Cloisonnement
Les données de contrôle ne devaient pas circuler hors du périmètre défini, ni transiter par un service tiers.
- 05
Coexistence avec l’existant
La mise en service devait se faire sans interrompre l’activité de contrôle en cours ni perdre l’historique récent.
La réponse AIGYROS
Ce que nous avons construit.
Nous avons commencé sur le terrain, en observant les gestes réels du contrôle : quelles informations sont consultées, dans quel ordre, à quel moment une décision est prise. Cette étape a redéfini le périmètre fonctionnel — moins d’écrans, mais les bons.
Le modèle de données a été construit autour de la notion d’obligation : une obligation, ses preuves attendues, son responsable, son échéance et ses décisions successives. Les logiciels existants alimentent ce modèle par des connecteurs, sans double saisie.
L’application a été déployée en environnement cloisonné, avec des profils d’accès distincts — consultation, saisie, validation — et un journal d’audit qui conserve chaque modification, y compris les corrections.
La mise en service s’est faite progressivement, périmètre par périmètre, en double tenue avec les tableurs le temps d’un cycle complet, puis bascule définitive une fois les écarts expliqués.
La conduite
Quatre temps, tenus dans cet ordre.
Les durées indiquées sont des ordres de grandeur de conduite, jamais des engagements : chaque mission est recalibrée sur son terrain.
- 01Phase d’immersion, sur le poste de travail
Observer
Observation des gestes réels du contrôle, cartographie des sources d’information, entretiens avec les équipes et les directions.
- Observation des gestes quotidiens de contrôle
- Cartographie des sources d’information
- Entretiens avec les équipes et les directions
- Reformulation écrite du besoin fonctionnel
- 02Phase de conception
Modéliser
Modèle de données fondé sur l’obligation, profils et droits, maquettes des écrans de contrôle, scénarios de contrôle externe.
- Modèle de données fondé sur l’obligation
- Définition des profils et des droits
- Maquettes des écrans de contrôle
- Scénarios de contrôle externe anticipés
- 03Phase de construction par étapes
Développer
Connecteurs vers les logiciels existants, application et journal d’audit, démonstrations régulières et recette conjointe.
- Connecteurs vers les logiciels existants
- Application et journal d’audit
- Démonstrations régulières aux équipes
- Recette fonctionnelle conduite avec les utilisateurs
- 04Phase de mise en service
Déployer
Double tenue avec les tableurs, formation des utilisateurs, bascule définitive par périmètre et suivi après mise en service.
- Double tenue avec les tableurs existants
- Formation des utilisateurs par profil
- Bascule définitive périmètre par périmètre
- Suivi des anomalies après mise en service
Ce qui change
Avant, après — sans chiffre de vitrine.
Nous ne publions pas de pourcentages de progression : ils ne se vérifient pas depuis l’extérieur. Ce qui se décrit, en revanche, c’est le geste quotidien qui change.
- Situation initialeAprès la mission
Situation initiale : Tableurs partagés, versions concurrentes
Après la mission : Une base unique, un état de conformité à jour
Situation initiale : Information saisie deux ou trois fois
Après la mission : Ressaisies supprimées, sources connectées
Situation initiale : Historique reconstitué à la main
Après la mission : Journal d’audit daté, attribué, conservé
Situation initiale : Échéances surveillées de mémoire
Après la mission : Alertes automatiques sur les obligations
Situation initiale : Accès indifférenciés au fichier partagé
Après la mission : Profils distincts : consultation, saisie, validation
Situation initiale : Contrôle externe redouté
Après la mission : Preuve exportable et vérifiable en quelques minutes
Les livrables
Ce qui reste entre vos mains.
Une mission se juge aussi à ce qu’elle laisse derrière elle. Chaque livrable est écrit pour être lu sans nous.
- 01
Modèle de données
La structure de l’obligation, de la preuve et de la décision, documentée et stable.
- 02
Application et connecteurs
L’outil de contrôle et ses liaisons aux logiciels métier existants, sans double saisie.
- 03
Journal d’audit
L’historique complet des décisions, consultable et exportable en cas de contrôle.
- 04
Dossier de recette
Scénarios testés, résultats obtenus et écarts acceptés, validés avec les utilisateurs.
- 05
Guide utilisateur par profil
Un mode d’emploi par rôle : consultation, saisie, validation.
- 06
Procédure de contrôle externe
Le déroulé d’une vérification par un tiers, depuis l’export jusqu’à la justification.
Le périmètre exclu
Ce que la mission n’incluait pas.
Un périmètre flou coûte plus cher qu’un périmètre incomplet. Nous l’écrivons donc noir sur blanc, dès la proposition : ce qui est traité, et ce qui ne l’est pas.
- Le remplacement des logiciels métier existants.
- L’interprétation juridique des obligations : les règles ont été fournies et validées par l’organisation.
- L’ouverture de l’application aux partenaires externes, étudiée dans un second temps.
- La reprise des tableurs historiques au-delà des deux derniers exercices.
Un contrôle ne vautque s’il laisse une trace.
Dossier
Outil de suivi réglementaire
Réalisation 03 — Application métier
Zone d'intervention : France / Monaco / Suisse
Autres dossiers de mission
Prendre contact
Votre contexte ressemble à l’un de ceux-ci ?
Décrivez-nous votre environnement, vos contraintes et ce qui ne peut pas être compromis. Nous répondons par une analyse, pas par un catalogue.