Document exemple partiel. Cet extrait présente 6 blocs représentatifs parmi les blocs couverts par un audit complet SocleRef. Il montre une partie de la structure réelle d’un rapport SocleRef et des exemples de preuves. Chaque bloc suit la même structure : constat · preuve · impact · action · priorité.
Résumé exécutif
Ce rapport présente l'état observé du référentiel client au moment de l'audit. Le socle est sérieux et plusieurs contrôles clés sont en place. Deux points restent à traiter avant de considérer le référentiel comme pleinement maîtrisé : la gouvernance des accès et la traçabilité des opérations de purge. Un troisième point n'a pas pu être vérifié faute d'accès au périmètre concerné : il est marqué NON AUDITÉ, car en l'absence de preuve, rien n'est conclu. Les blocs non validés reflètent l'état constaté - ils ne traduisent pas une limite de la méthode, mais une situation à corriger.
Priorité immédiate
1
Priorité haute
1
Priorité moyenne
0
Non audité
1
Validé
3
Sans correction de ces deux points, l'entreprise ne peut pas démontrer qui est autorisé à accéder aux données sensibles, ni apporter la preuve finale qu'une opération de purge a bien été exécutée. Ces lacunes exposent l'entreprise à un risque documentaire réel en cas d'audit, de litige ou de demande RGPD.
Analyse - Extraits de blocs
6 blocs représentatifs. Chaque bloc suit la même structure : constat · preuve · impact · action · priorité.
BLOC 1 / 6
Gouvernance des accès
NON VALIDÉ
Priorité immédiate
Risque métier
L'entreprise ne peut pas démontrer clairement qui est autorisé à administrer, consulter ou purger les données sensibles.
Constat
Le contrôle montre une séparation insuffisante des rôles sensibles. Un rôle technique principal est présent, mais les rôles de séparation attendus ne sont pas suffisamment démontrés. Aucune matrice complète des droits ne peut être validée sur les éléments fournis.
Preuve
Préaudit en lecture seule réalisé sur la source de vérité. Extrait de résultat :
| Dimension contrôlée | Statut |
|---|---|
| Rôle technique principal | présent |
| Séparation des rôles sensibles | non démontrée |
| Matrice des droits | non validée |
| Rattachement aux rôles cibles | non démontré |
| Preuve finale | absente |
Les noms de champs, tables, clés techniques et résultats bruts sont masqués dans cet extrait public.
Impact
La gouvernance des accès n'est pas complète. Conséquences concrètes pour la direction :
- L'entreprise ne peut pas prouver qui avait le droit de lire, modifier ou purger les données sensibles à un instant donné
- Impossible de déléguer les opérations de purge à un rôle dédié sans passer par un compte superuser - ce qui contredit toute politique de séparation des droits
- En cas de contrôle ou d'incident, l'absence de matrice des droits formalisée est un point de faiblesse documentaire direct
Action
- Créer les rôles attendus après décision humaine explicite
- Appliquer les droits nécessaires et vérifier les permissions effectives
- Produire une preuve finale exploitable
- Valider la matrice des droits et figer le bloc après preuve finale
Priorité
Immédiate
Dossier de preuve
Le dossier complet est fourni dans la version client : éléments vérifiés, corrections et preuve finale.
BLOC 2 / 6
Traçabilité des opérations de purge
NON VALIDÉ
Priorité haute
Risque métier
En cas de demande client, de contrôle ou de besoin RGPD, l'entreprise ne peut pas démontrer qu'une purge a réellement été exécutée, ni sur quel périmètre.
Constat
Le bloc de purge est cadré, mais aucune exécution réelle n'a encore produit de preuve finale. Le dossier de preuve de purge ne permet pas de démontrer l'opération sur un périmètre contrôlé.
Preuve
Extrait de contrôle :
| Élément contrôlé | Résultat |
|---|---|
| Cadre de purge | présent |
| Périmètre | défini |
| Preuve d'exécution réelle | absente |
| Preuve finale | absente |
| Journal de purge exploitable | non démontré |
Les noms de champs, tables, clés techniques et résultats bruts sont masqués dans cet extrait public.
Impact
En cas de demande client, de contrôle RGPD ou d'audit interne, l'entreprise ne peut pas démontrer :
- Qu'une purge a réellement été exécutée et à quelle date
- Sur quel périmètre de données et par quel acteur identifié
- Quel volume a été supprimé et quelle preuve a été conservée
Action
- Exécuter le préflight sur la source de vérité
- Exécuter le script principal et produire la preuve finale
- Contrôler l'immutabilité du journal
- Valider humainement le bloc avant figement
Priorité
Haute
BLOC 3 / 6
Protection des documents émis
VALIDÉ
Lecture métier
Une facture ou un avoir émis doit rester stable ; sinon l'entreprise peut avoir des difficultés à justifier l'état exact du document en cas de litige.
Constat
Les documents émis de type facture ou avoir sont protégés contre les modifications sensibles. La garde d'immutabilité est portée au niveau PostgreSQL.
Preuve
Preuves retenues :
- Mécanisme de protection actif
- Modification sensible refusée
- Preuve finale conforme
- Contrôle validé et documenté
Impact
Une facture ou un avoir émis ne peut plus être modifié silencieusement. La preuve ne dépend pas uniquement de l'application - elle est portée par la base de données. En cas de litige, l'entreprise peut démontrer que le document émis est protégé.
Action
Bloc validé. Maintenir la conservation des preuves finales et vérifier ce point lors des évolutions futures.
Priorité
Basse - bloc clos
BLOC 4 / 6
Prévention des doublons documentaires
VALIDÉ
Lecture métier
Le référentiel doit empêcher l'apparition de doublons documentaires afin d'éviter des erreurs de facturation, de suivi client ou de rapprochement comptable.
Constat
Le référentiel empêche la création de doublons documentaires par client, type et référence. Une règle de contrôle d'unicité protège l'unicité des documents lorsque la référence est renseignée.
Preuve
Extrait de contrôle :
| Comportement contrôlé | Résultat |
|---|---|
| Premier enregistrement | accepté |
| Doublon logique | refusé |
| Retour arrière final | propre |
Les noms de champs, tables, clés techniques et résultats bruts sont masqués dans cet extrait public.
Impact
Le référentiel ne laisse pas entrer silencieusement deux factures avec la même référence pour un même client. La règle est appliquée au niveau PostgreSQL, indépendamment de la couche applicative.
Action
Bloc validé. Vérifier ce point lors des évolutions futures afin d'éviter toute régression sur le contrôle d'unicité.
Priorité
Basse - bloc clos
BLOC 5 / 6
Historique des actions métier
VALIDÉ
Lecture métier
L'entreprise doit pouvoir expliquer qui a agi, sur quel document, pour quel client, à quelle date et dans quel contexte.
Constat
Le référentiel dispose d'un journal d'événements exploitable. Les dimensions nécessaires pour relire une action métier sont présentes : acteur, action, objet concerné, périmètre et horodatage.
Preuve
Extrait de contrôle :
| Dimension contrôlée | Statut |
|---|---|
| Acteur | présent |
| Action | présent |
| Objet concerné | présent |
| Périmètre client | présent |
| Horodatage | présent |
| Intégrité des rattachements | validée |
Les noms de champs, tables, clés techniques et résultats bruts sont masqués dans cet extrait public.
Impact
Le référentiel peut répondre aux questions :
- Qui a agi, sur quel document, pour quel client
- À quelle date et avec quel type d'action
Action
Bloc validé. Maintenir une preuve finale claire et exploitable pour les contrôles futurs.
Priorité
Basse - bloc clos
BLOC 6 / 6
Contrôle des informations d'émission
NON AUDITÉ
Lecture métier
Au moment de l'émission d'une facture, les informations essentielles doivent être présentes et conservées pour pouvoir justifier l'état du document plus tard.
Constat
Ce point n'a pas pu être vérifié dans le périmètre fourni. L'accès à l'historique d'émission et aux journaux associés n'a pas été transmis au moment de l'audit. Aucune preuve n'a donc pu être produite, ni dans un sens ni dans l'autre.
Preuve
Aucune preuve produite. Éléments non disponibles :
- Accès au périmètre d'émission non fourni
- Journaux associés hors du périmètre transmis
- Aucun élément permettant de rejouer le contrôle
Impact
En l'absence de preuve, ce point ne peut être ni validé ni invalidé. Il reste une zone non démontrée : tant qu'elle n'est pas auditée, l'entreprise ne peut pas affirmer que l'état d'émission est conservé et protégé.
Action
Fournir le périmètre en lecture et rejouer le contrôle. Le bloc passera alors en VALIDÉ ou NON VALIDÉ selon le résultat.
Priorité
À compléter - accès requis
Blocs supplémentaires disponibles dans le rapport complet
Rapport complet
Conclusion de l'extrait
Sur les 6 blocs présentés : 3 blocs validés avec preuves exploitables · 1 non validé priorité haute · 1 non validé priorité immédiate · 1 non audité faute d'accès au périmètre concerné.
Les deux points à traiter en priorité sont clairs et documentés. Le point non audité n'est ni validé ni invalidé : tant qu'aucune preuve n'est produite, aucune conclusion n'est posée. Une fois les accès fournis et les corrections prouvées, le référentiel pourra être considéré comme maîtrisé sur le périmètre audité.