Document exemple partiel. Cet extrait présente 6 blocs représentatifs parmi les blocs couverts par un audit complet Socleref. Il illustre la structure, la logique et le niveau de détail du rapport livré au client. Chaque bloc suit la même structure : constat · preuve · impact · action · priorité.
Résumé exécutif
Le socle est sérieux, mais deux points empêchent encore de considérer le référentiel comme pleinement maîtrisé : la gouvernance des rôles et la preuve finale des purges.
Priorité immédiate
1
Priorité haute
1
Priorité moyenne
0
Priorité basse
0
Validé
4
Sans correction des deux points critiques, l'entreprise ne peut pas prouver complètement qui accède aux données sensibles, ni garantir la traçabilité finale des purges.
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
Constat
Trois rôles de gouvernance attendus sont absents : rôle d'administration, rôle de purge et rôle de lecture dédiée. Seul le rôle propriétaire est présent. Aucune matrice complète des droits ne peut être validée.
Preuve
Préaudit en lecture seule réalisé sur la source de vérité. Résultat constaté :
- Rôle propriétaire : présent
- Rôle administrateur : absent
- Rôle purge : absent
- Rôle lecteur : absent
- Aucun membership observé sur les rôles ciblés
- Aucun preuve finale d'exécution produit
Impact
La gouvernance des accès n'est pas complète. Deux risques principaux :
- Impossibilité de restreindre proprement la lecture des journaux d'audit
- Impossibilité de déléguer les opérations de purge à un rôle dédié non-superuser
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
BLOC 2 / 6
Traçabilité des opérations de purge
NON VALIDÉ
Priorité haute
Constat
Le bloc est correctement structuré : contrat, scripts SQL, périmètre et conditions de fermeture sont définis. Mais aucune exécution réelle n'a encore produit de preuve finale. Le dossier des logs est vide.
Preuve
Éléments présents : contrat du bloc, script de préflight, script principal, colonnes attendues documentées, conservation des traces prévue.
Manquants :
Manquants :
- Aucun preuve finale d'exécution
- Aucune preuve d'exécution réelle
- Aucune preuve de mécanisme de purge vérifiable
Impact
En cas de demande client, de contrôle ou de besoin RGPD, l'entreprise ne peut pas démontrer :
- Quand une purge a été effectuée
- Sur quel périmètre et par quel acteur
- Avec quel volume supprimé et quelle preuve conservée
Action
- Exécuter le préflight sur la source de vérité
- Exécuter le script principal et produire le preuve finale d'exécution
- Contrôler l'immutabilité du journal
- Valider humainement le bloc avant figement
Priorité
Haute
BLOC 3 / 6
Protection des documents émis
VALIDÉ
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
- Tentative de modification refusée — preuve produite
- Correction structurelle appliquée et validée
- 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 l'archivage des logs intermédiaires et conserver une seule preuve finale active par bloc.
Priorité
Basse — bloc clos
BLOC 4 / 6
Prévention des doublons documentaires
VALIDÉ
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
Comportement observé :
- Insertion d'un premier document : acceptée
- Insertion d'un second document avec même référence, même type et même client : refusée
- Rollback final : propre
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é. Ajouter une vérification dans les migrations futures pour détecter toute suppression accidentelle de le contrôle technique d'unicité.
Priorité
Basse — bloc clos
BLOC 5 / 6
Historique des actions métier
VALIDÉ
Constat
Le référentiel dispose d'un journal technique d'événements rattaché au client et au document concerné. Le journal porte les champs nécessaires pour filtrer les actions par client, document, type d'action et horodatage.
Preuve
Preuves retenues :
- Schéma de la table d'événements conforme
- Clés étrangères actives vers client et document
- isolation des accès validée
- Preuve finale conforme
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 la convention de nommage des logs finaux et conserver l'obligation de preuve finale unique.
Priorité
Basse — bloc clos
BLOC 6 / 6
Contrôle des informations d'émission
VALIDÉ
Constat
L'émission d'une facture est bloquée si les informations obligatoires minimales sont absentes. Lorsqu'une facture est émise, un état de référence conservé et protégé.
Preuve
Preuves retenues :
- Refus d'émission si référence manquante
- Refus d'émission si entité légale émettrice absente
- Refus d'émission si adresse client absente
- Création d'un état de référence conservé et protection contre les modifications ultérieures
Impact
En cas de litige, l'entreprise peut démontrer quelles informations étaient présentes au moment où la facture a été produite. Le état de référence figé conserve l'état du document à l'émission.
Action
Bloc validé. Pour un audit ultérieur, vérifier que les clients créés avant migration disposent des champs nécessaires à l'émission conforme.
Priorité
Basse — bloc clos
Blocs supplémentaires disponibles dans le rapport complet
Rapport complet
Conclusion de l'extrait
Sur les 6 blocs présentés : 4 blocs sont validés avec preuves exploitables · 1 bloc non validé gravité élevée · 1 bloc non validé gravité critique.
Le référentiel présente une base sérieuse, mais deux points doivent être traités avant de considérer le socle comme pleinement maîtrisé : la gouvernance des rôles et la preuve finale des opérations de purge.