Checklist de Conformité ISCA — Scell.io
Article 286-I-3° bis du CGI (LF 2026, art. 125)
Destinataire : Agent d'audit automatisé sur le code source de l'application Référentiel : BOI-TVA-DECLA-30-10-30, NF525 (INFOCERT/AFNOR), CGI art. 286-I-3° bis Date de référence réglementaire : LF 2026 adoptée le 2 février 2026 — auto-attestation rétablie
CONTEXTE RÉGLEMENTAIRE
Scell.io est un microservice API-only de facturation et encaissement. Dès lors qu'il permet d'enregistrer des règlements de clients particuliers (B2C) pour le compte d'assujettis TVA, il constitue un logiciel de caisse au sens du BOFiP et doit satisfaire aux 4 conditions ISCA :
- Inaltérabilité des données
- Sécurisation des données
- Conservation des données
- Archivage des données
La conformité peut être justifiée soit par un certificat NF525 (INFOCERT/AFNOR ou LNE), soit par une auto-attestation individuelle de l'éditeur conforme au modèle de l'administration (rétabli par l'article 125 de la LF 2026).
Sanction en cas de non-conformité : 7 500 € d'amende par logiciel ou système non conforme (art. 1770 duodecies du CGI), avec obligation de régularisation dans les 60 jours.
INSTRUCTIONS POUR L'AGENT D'AUDIT
Pour chaque point de contrôle ci-dessous :
- [CONFORME] : Le code implémente correctement l'exigence. Citer le fichier et la ligne.
- [NON-CONFORME] : L'exigence n'est pas implémentée ou est défaillante. Décrire le manque.
- [PARTIEL] : L'implémentation est incomplète ou ambiguë. Décrire ce qui manque.
- [NON-APPLICABLE] : L'exigence ne s'applique pas au périmètre actuel. Justifier.
⚠️ RÈGLE CRITIQUE : Toute modification corrective suggérée à l'issue de cet audit ne doit pas casser les fonctionnalités existantes. Signaler systématiquement les risques de régression pour chaque recommandation.
PILIER 1 — INALTÉRABILITÉ (I)
L'objectif est de garantir qu'aucune donnée de règlement enregistrée ne puisse être modifiée ou supprimée sans que cela soit détecté et tracé.
1.1 — Enregistrement irréversible des transactions
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| I-01 | Aucun UPDATE/DELETE sur les données fiscales | Vérifier qu'il n'existe aucune requête SQL UPDATE ou DELETE sur les tables contenant des factures émises, factures encaissées, avoirs, tickets, et lignes d'encaissement. Seuls les INSERT sont autorisés. Les brouillons (drafts) peuvent être modifiés. | |
| I-02 | Soft-delete interdit sur données fiscales | Vérifier qu'aucun mécanisme de soft-delete (colonne deleted_at, scope withTrashed, trait SoftDeletes de Laravel) n'est appliqué aux modèles de données fiscales figées (factures émises, encaissements, avoirs, logs fiscaux). | |
| I-03 | Statut légal explicite sur chaque objet | Chaque entité doit porter un attribut de statut légal (ex: legal_status = draft / fiscal / proof) qui détermine son régime de protection. Vérifier la présence de cet attribut dans les modèles et migrations. | |
| I-04 | Transition de statut irréversible | Vérifier qu'une facture passant de draft à émise ne peut jamais revenir en draft. La transition doit être unidirectionnelle et journalisée. Chercher toute logique de retour en arrière. | |
| I-05 | Correction par avoir uniquement | Vérifier qu'en cas d'erreur sur une facture émise, la seule mécanique possible est l'émission d'un avoir (credit note) qui référence la facture d'origine, et non la modification de la facture originale. | |
| I-06 | Numérotation séquentielle sans rupture | Vérifier que les numéros de factures et avoirs sont générés séquentiellement, sans possibilité de trous dans la numérotation. Chercher un mécanisme de vérification de continuité (ex: contrainte DB, vérification applicative). |
1.2 — Chaînage cryptographique des écritures
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| I-07 | Hash de chaque écriture fiscale | Chaque enregistrement fiscal (facture, avoir, encaissement) doit contenir un hash (SHA-256 minimum) calculé à partir de ses données significatives. Vérifier la présence d'une colonne hash ou checksum et la logique de calcul. | |
| I-08 | Chaînage des hash | Le hash de chaque écriture doit inclure le hash de l'écriture précédente dans la même chaîne, formant une chaîne liée. Vérifier la présence d'un champ previous_hash et son utilisation dans le calcul du hash courant. | |
| I-09 | Données incluses dans le hash | Le hash doit couvrir au minimum : montant TTC, montant HT, TVA, date/heure, numéro séquentiel, identifiant client, mode de paiement, hash précédent. Vérifier la fonction de calcul. | |
| I-10 | Algorithme de hachage documenté | L'algorithme utilisé (SHA-256, SHA-512…) doit être explicitement documenté et constant. Vérifier qu'il n'est pas configurable de manière à permettre un downgrade. | |
| I-11 | Vérification d'intégrité de la chaîne | Il doit exister une fonction permettant de recalculer l'ensemble de la chaîne de hash et de détecter toute altération. Chercher une commande artisan, un endpoint API ou un service dédié. |
1.3 — Protection contre les modifications administrateur
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| I-12 | Pas de route admin de modification fiscale | Vérifier qu'aucun endpoint API (route, controller) ne permet à un admin de modifier ou supprimer une donnée fiscale figée, même via un panel d'administration. | |
| I-13 | Protection au niveau base de données | Vérifier l'existence de triggers DB, policies Laravel, ou middleware empêchant techniquement la modification, indépendamment de la couche applicative. | |
| I-14 | Journalisation des tentatives de modification | Toute tentative de modification d'une donnée fiscale figée (même échouée) doit être loguée avec : timestamp, identité de l'opérateur, donnée ciblée, action tentée. |
PILIER 2 — SÉCURISATION (S)
L'objectif est de protéger les données d'origine, les modifications éventuelles et les pièces justificatives par des mécanismes cryptographiques.
2.1 — Signature / Condensat des enregistrements
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| S-01 | Signature ou condensat sur chaque transaction | Chaque pièce justificative (ticket, facture, avoir) doit être protégée par un condensat (hash) ou une signature électronique. Vérifier que la génération est automatique et non contournable. | |
| S-02 | Clé de signature protégée | Si une signature est utilisée (au-delà du simple hash), vérifier que la clé privée est stockée de manière sécurisée (variables d'environnement, vault, pas en dur dans le code). | |
| S-03 | Horodatage de chaque opération | Chaque événement fiscal doit être horodaté en UTC. Vérifier la présence systématique d'un timestamp fiable (pas modifiable par l'utilisateur) sur chaque écriture. | |
| S-04 | Double horodatage (optionnel mais recommandé PRD) | Le PRD prévoit un horodatage externe optionnel (RFC 3161 / TSA). Vérifier si cette fonctionnalité est implémentée ou prévue. |
2.2 — Journalisation sécurisée
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| S-05 | Journal des événements fiscaux (ledger) | Vérifier l'existence d'un journal (table de logs) enregistrant tous les événements fiscaux : création, clôture, export, tentative de modification. Ce journal doit lui-même être protégé en écriture seule (append-only). | |
| S-06 | Chaînage du journal | Le journal fiscal doit lui-même être chaîné (chaque entrée contient le hash de la précédente) pour prévenir l'insertion ou la suppression d'entrées. | |
| S-07 | Triple journalisation (exigence PRD) | Le PRD prévoit 3 journaux indépendants : ledger opérationnel, ledger probatoire (lecture seule), journal d'intégrité (métalog). Vérifier leur existence et leur indépendance. | |
| S-08 | Journalisation des accès | Les accès aux données fiscales (lecture, export) doivent être tracés. Vérifier l'existence d'un audit trail des accès. |
2.3 — Contrôle d'accès et séparation des rôles
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| S-09 | Authentification obligatoire | Tous les endpoints fiscaux doivent être protégés par authentification (middleware auth, token API, etc.). Aucun endpoint fiscal ne doit être accessible sans authentification. | |
| S-10 | Séparation des rôles | Vérifier l'existence de rôles distincts (ex: écriture, clôture, export, attestation) comme prévu dans le PRD §9. Aucun rôle unique ne doit permettre toutes les opérations. | |
| S-11 | Protection des clés cryptographiques | Les clés de hachage/signature ne doivent pas être stockées en clair dans le code source ou les fichiers de configuration versionnés. Chercher dans .env, config/, et le code source. |
PILIER 3 — CONSERVATION (C)
L'objectif est de permettre le calcul et l'enregistrement des données cumulatives et récapitulatives dans le cadre de clôtures périodiques.
3.1 — Clôtures périodiques
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| C-01 | Clôture journalière | Vérifier l'existence d'un mécanisme de clôture quotidienne qui verrouille la période. Chercher un job CRON, une commande artisan, ou un service dédié. | |
| C-02 | Clôture mensuelle | Vérifier l'existence d'un mécanisme de clôture mensuelle. | |
| C-03 | Clôture annuelle / par exercice | Vérifier l'existence d'un mécanisme de clôture annuelle ou par exercice fiscal. | |
| C-04 | Irréversibilité des clôtures | Une fois clôturée, une période ne doit plus accepter d'écriture. Vérifier que toute tentative d'écriture sur une période clôturée est rejetée ET journalisée (comme exigé par le PRD §6). | |
| C-05 | Données cumulatives et récapitulatives | À chaque clôture, le système doit calculer et stocker les totaux cumulatifs (grand total perpétuel) et récapitulatifs (total de la période) : CA TTC, CA HT, TVA par taux, nombre de transactions, ventilation par mode de paiement. Vérifier le modèle de données et la logique de calcul. | |
| C-06 | Grands totaux (totaux perpétuels) | Les grands totaux sont des compteurs cumulatifs depuis la mise en service du logiciel. Ils ne peuvent jamais être remis à zéro. Vérifier leur existence et qu'aucune logique de reset n'existe. |
3.2 — Durée de conservation
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| C-07 | Conservation 6 ans minimum | Les données d'encaissement doivent être conservées pendant 6 ans (+ l'exercice en cours, soit 7 ans si exercice décalé). Vérifier qu'aucune purge automatique ne supprime des données fiscales avant ce délai. | |
| C-08 | Pas de purge automatique des données fiscales | Chercher toute commande de nettoyage, job de purge, ou mécanisme de rétention qui pourrait supprimer des données fiscales avant le délai légal. | |
| C-09 | Accès en lecture aux données historiques | Les données conservées doivent rester lisibles et accessibles pendant toute la durée de conservation. Vérifier qu'aucun mécanisme ne rend les données anciennes inaccessibles (compression opaque, chiffrement sans clé accessible…). |
PILIER 4 — ARCHIVAGE (A)
L'objectif est de produire des archives fiscales figées et datées, dans un format ouvert, lisibles par l'administration fiscale.
4.1 — Production d'archives fiscales
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| A-01 | Fonction d'archivage | Vérifier l'existence d'une fonction d'archivage déclenchable (manuellement ou automatiquement) produisant une archive sécurisée des données fiscales d'une période. | |
| A-02 | Périodicité d'archivage | L'archivage doit être possible au minimum annuellement (ou par exercice). Vérifier que la périodicité est configurable et ne dépasse pas un exercice. | |
| A-03 | Format ouvert et lisible | L'archive doit être dans un format ouvert (XML, CSV, JSON…) lisible sans dépendance au logiciel Scell.io. Vérifier le format de sortie de l'export d'archivage. | |
| A-04 | Intégrité de l'archive | L'archive produite doit contenir un hash ou une signature permettant de vérifier qu'elle n'a pas été altérée après sa production. | |
| A-05 | Traçabilité de la production d'archive | La production de chaque archive doit être journalisée : date de production, périmètre, hash de l'archive, identité de l'opérateur. | |
| A-06 | Conformité des données archivées avec les données source | Il doit être possible de vérifier que l'archive est fidèle aux données d'origine. Chercher un mécanisme de vérification croisée. |
4.2 — Export fiscal pour contrôle
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| A-07 | Export sur demande | L'administration fiscale doit pouvoir obtenir un export des données sur une période donnée. Vérifier l'existence d'un endpoint ou d'une commande dédiée. | |
| A-08 | Contenu de l'export | L'export doit contenir au minimum : toutes les pièces justificatives (factures, avoirs, tickets), les données de clôtures (journalières, mensuelles, annuelles), les grands totaux, le journal des événements. | |
| A-09 | Autonomie de l'export | L'export doit être intelligible indépendamment du système (pas de référence à des identifiants internes sans correspondance lisible). Vérifier la présence de libellés, noms, descriptions en clair. | |
| A-10 | Archivage résistant à la purge | Même si une purge des données opérationnelles est effectuée (après le délai légal), les archives produites antérieurement doivent rester accessibles. Vérifier que l'archivage et les données opérationnelles sont sur des supports/tables séparés. |
EXIGENCES COMPLÉMENTAIRES (PRD Scell.io + Bonnes pratiques)
Ces points vont au-delà du minimum légal mais sont prévus par le PRD ou constituent des bonnes pratiques fortement recommandées.
5.1 — Exigences PRD spécifiques
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| P-01 | Moteur de règles fiscales versionné | PRD §2 : Existence d'un moteur de règles déclaratif (YAML/JSON) avec historique complet et possibilité de rejeu sur données passées. | |
| P-02 | Empreintes publiques (proof anchoring) | PRD §5 : Hash racine journalier optionnel ancrable sur un registre externe (blockchain, notaire numérique). | |
| P-03 | Mode forensic replay | PRD §7 : Capacité à rejouer chronologiquement toutes les écritures et recalculer les hash pour produire un rapport d'intégrité. | |
| P-04 | Exports judiciaires avancés | PRD §8 : Au-delà des exports fiscaux, capacité à produire une chronologie certifiée, un graphe des dépendances, un rapport expert. | |
| P-05 | Kill-switch fiscal | PRD §10 : Capacité à bloquer toute écriture fiscale en cas d'incident grave tout en préservant la lecture et les preuves. | |
| P-06 | Indicateurs de conformité temps réel | PRD §15 : Dashboard ou endpoint affichant le % de périodes clôturées, % chaînes intactes, incidents ouverts, statut conformité global. |
5.2 — Auto-attestation éditeur
| # | Point de contrôle | Ce que l'agent doit vérifier dans le code | Résultat |
|---|---|---|---|
| ATT-01 | Génération d'attestation | Le système doit pouvoir générer une attestation individuelle conforme au modèle BOI-LETTRE-000242 pour chaque version déployée. | |
| ATT-02 | Contenu de l'attestation | L'attestation doit inclure : nom de l'éditeur (QR Communication SAS), nom du logiciel (Scell.io), version, numéro de licence, date de mise sur le marché, déclaration de conformité ISCA. | |
| ATT-03 | Versioning et traçabilité | Chaque version majeure (modifiant un paramètre ISCA) nécessite une nouvelle attestation. Vérifier la gestion des versions majeures vs mineures. |
POINTS DE VIGILANCE — RISQUES DE RÉGRESSION
Lors de toute correction ou évolution, l'agent doit signaler les risques suivants :
| Risque | Description | Vérification |
|---|---|---|
| Régression chaînage | Toute modification du modèle de données d'une entité fiscale peut casser le calcul du hash et invalider toute la chaîne postérieure. | Avant toute migration, vérifier que les champs utilisés dans le calcul du hash ne sont pas impactés. |
| Régression clôture | L'ajout d'une nouvelle écriture ou d'un nouveau type de transaction pourrait échapper au verrouillage des clôtures. | Vérifier que tout nouveau type d'écriture passe par la vérification de période clôturée. |
| Régression export | L'ajout de champs ou la modification de la structure peut rendre les exports incompatibles avec les archives précédentes. | Tester la rétrocompatibilité des exports avant et après modification. |
| Régression séquencement | Toute modification de la logique de numérotation peut créer des trous ou des doublons. | Tester la continuité séquentielle sur un jeu de données existant. |
| Régression horodatage | Un changement de timezone ou de format de date peut invalider les preuves temporelles. | Vérifier que tous les timestamps restent en UTC et au même format. |
RÉSUMÉ DES CONDITIONS LÉGALES
| Condition | Article | Résumé | Points de contrôle |
|---|---|---|---|
| Inaltérabilité | Art. 286-I-3° bis CGI | Toutes les données de règlement sont enregistrées sans possibilité de modification ou suppression | I-01 à I-14 |
| Sécurisation | Art. 286-I-3° bis CGI | Les données d'origine, les modifications et les pièces justificatives sont sécurisées par hachage ou signature | S-01 à S-11 |
| Conservation | Art. 286-I-3° bis CGI | Clôtures journalières/mensuelles/annuelles avec données cumulatives intègres, conservation 6 ans | C-01 à C-09 |
| Archivage | Art. 286-I-3° bis CGI | Archive sécurisée en format ouvert, périodicité max annuelle, intégrité garantie | A-01 à A-10 |
MODE OPÉRATOIRE POUR L'AGENT
- Scanner l'arborescence du projet Laravel (Models, Migrations, Controllers, Services, Jobs, Commands)
- Pour chaque point de contrôle, chercher l'implémentation correspondante dans le code
- Documenter le résultat avec le fichier et la ligne exacte
- Signaler tout risque de régression pour chaque recommandation
- Produire un rapport final avec le statut de chaque point : CONFORME / NON-CONFORME / PARTIEL / NON-APPLICABLE
- Prioriser les non-conformités : P0 (bloquant légalement), P1 (risque élevé), P2 (amélioration recommandée)
Document généré le 08/02/2026 — Référentiel : BOI-TVA-DECLA-30-10-30 (mise à jour 01/10/2025), LF 2026 art. 125, PRD Scell.io v2000%