Document exemple partiel. Cet extrait présente 6 blocs représentatifs parmi les 20 blocs couverts par un audit complet Sceleo. 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 rôles & permissions
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 log final consolidé 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 un log final consolidé
- Valider la matrice des droits et figer le bloc après preuve finale
Priorité
Immédiate
BLOC 2 / 6
Journal de purge & preuve finale
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, trigger append-only prévu.
Manquants :
Manquants :
- Aucun log final consolidé
- Aucune preuve d'exécution réelle
- Aucune preuve de table de purge opérationnelle
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 log final consolidé
- Contrôler l'immutabilité du journal
- Valider humainement le bloc avant figement
Priorité
Haute
BLOC 3 / 6
Immutabilité 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 :
- Fonction de garde d'immutabilité active
- Tentative de modification refusée — preuve produite
- Correction structurelle appliquée et validée
- Bloc clôturé et figé
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
Anti-doublon & contrainte unique
VALIDÉ
Constat
Le référentiel empêche la création de doublons documentaires par client, type et référence. Une contrainte unique partielle 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 l'index unique.
Priorité
Basse — bloc clos
BLOC 5 / 6
Traçabilité client-scoped
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
- RLS activé et forcé — policies présentes
- Log final conforme après correction de nommage
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
Mentions obligatoires facture & snapshot légal
VALIDÉ
Constat
L'émission d'une facture est bloquée si les informations obligatoires minimales sont absentes. Lorsqu'une facture est émise, un snapshot légal est créé et rendu immuable.
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 snapshot légal et trigger empêchant toute modification
Impact
En cas de litige, l'entreprise peut démontrer quelles informations étaient présentes au moment où la facture a été produite. Le snapshot légal 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.