Sécuriser les données comptables dans un système automatisé

Maxime Reding

Vous êtes sur le point de connecter les cartes de paiement, les factures fournisseurs et le logiciel comptable. Les saisies manuelles vont diminuer, mais votre commissaire aux comptes posera toujours la même question :

Qui a créé, validé ou modifié cette dépense ?

Avec l’automatisation, le risque ne disparaît pas. Il se déplace.

Il concerne désormais :

  • les règles de validation ;

  • les droits d’accès ;

  • les comptes techniques ;

  • les intégrations ;

  • les sauvegardes ;

  • les historiques de modification ;

  • la qualité des données transmises entre les outils.

Sécuriser les données comptables ne consiste donc pas uniquement à choisir un logiciel protégé. Il faut aussi organiser les droits, séparer les responsabilités, surveiller les intégrations et conserver les preuves nécessaires.

Dans cet article, découvrez les principaux risques d’un système comptable automatisé et les contrôles à mettre en place pour protéger vos données et démontrer votre conformité.

📌 À retenir

  • L’automatisation déplace le risque de la saisie vers les règles, les accès et les intégrations.
  • Le principe du moindre privilège limite les actions accessibles à chaque utilisateur.
  • La séparation des tâches doit empêcher une même personne de créer un fournisseur, de modifier ses coordonnées bancaires et d’exécuter son paiement.
  • Une piste d’audit doit permettre de retrouver qui a fait quoi, quand et sur quelle donnée.
  • Chaque connecteur doit avoir un responsable, un périmètre de données et une procédure en cas d’échec.
  • Les sauvegardes doivent être isolées et régulièrement testées.
  • L’entreprise reste responsable de la configuration de ses utilisateurs, de ses règles et de ses contrôles, même lorsque le logiciel est fourni en SaaS.
  • Le logiciel comptable produit le FEC. Les outils en amont doivent lui transmettre des données correctement mappées et traçables.

L’automatisation déplace les risques du système comptable

Dans un processus manuel, une erreur peut concerner une facture ou une écriture. Dans un système automatisé, une mauvaise règle peut reproduire la même erreur sur des centaines d’opérations.

Les principaux risques se concentrent dans trois zones.

Les règles

Une règle d’approbation mal configurée peut autoriser automatiquement une dépense au-delà du seuil prévu.

Une règle de catégorisation incorrecte peut affecter plusieurs transactions au mauvais compte.

Une règle de synchronisation incomplète peut empêcher certaines données d’atteindre le logiciel comptable.

Les comptes et les intégrations

Un connecteur possède souvent des droits d’accès aux données financières. Si ses identifiants sont partagés, trop anciens ou trop larges, il devient une porte d’entrée supplémentaire vers le système comptable.

Les droits utilisateurs

Un collaborateur qui change de poste peut conserver des droits devenus inutiles. Un administrateur peut modifier une règle sans qu’une seconde personne soit informée. Un utilisateur peut cumuler des droits incompatibles avec son rôle.

La protection des données comptables poursuit donc trois objectifs :

  • empêcher les accès non autorisés ;

  • préserver l’intégrité des données ;

  • pouvoir démontrer que les contrôles ont fonctionné.

Quatre axes pour sécuriser un système comptable automatisé

Une organisation peut structurer ses contrôles autour de quatre axes.

1. Les accès

Appliquez le principe du moindre privilège. Chaque personne doit disposer uniquement des droits nécessaires à sa mission.

Activez une authentification renforcée pour les comptes qui :

  • approuvent les dépenses ;

  • exécutent les paiements ;

  • modifient les coordonnées bancaires ;

  • administrent les utilisateurs ;

  • configurent les règles ;

  • exportent les données comptables.

2. La traçabilité

Conservez un historique des opérations importantes :

  • création et modification d’un fournisseur ;

  • changement de coordonnées bancaires ;

  • modification d’une règle ;

  • validation d’une facture ;

  • correction d’un compte ;

  • export de données ;

  • changement de rôle ;

  • connexion d’un compte technique.

L’historique doit permettre d’identifier l’auteur, la date, l’heure et la nature de l’action.

3. Les intégrations et les sauvegardes

Chaque connecteur doit avoir :

  • un responsable métier ;

  • un responsable technique ;

  • un périmètre de données documenté ;

  • des identifiants protégés ;

  • une procédure de rotation ;

  • une alerte en cas d’échec ;

  • une procédure de reprise.

Les sauvegardes doivent être protégées contre une suppression ou une modification simultanée du système principal. Leur restauration doit être testée régulièrement.

4. Le fournisseur

L’évaluation d’un logiciel ne doit pas reposer uniquement sur ses fonctionnalités.

Demandez également :

  • où les données sont hébergées ;

  • comment les accès sont protégés ;

  • comment les incidents sont signalés ;

  • quelles sont les certifications ou qualifications pertinentes ;

  • quels sous-traitants interviennent ;

  • comment les données sont restituées en fin de contrat ;

  • quels éléments sont disponibles pour les audits.

Le contrôle des accès repose sur le moindre privilège

Le principe du moindre privilège consiste à attribuer à chaque utilisateur les seuls droits nécessaires à son rôle.

La CNIL recommande de structurer les habilitations en fonction des responsabilités et de retirer les droits devenus inutiles.

Dans un service finance, on peut distinguer plusieurs profils :

  • Le demandeur initie une dépense ou une demande d’achat.

  • L’approbateur valide les dépenses de son périmètre.

  • Le payeur exécute les paiements approuvés.

  • Le comptable contrôle, impute et exporte les écritures.

  • L’administrateur configure les utilisateurs, les règles et les paramètres.

Ces profils doivent être séparés autant que possible.

Une même personne ne devrait pas pouvoir :

  1. créer un fournisseur ;

  2. modifier son IBAN ;

  3. approuver une facture ;

  4. exécuter le paiement ;

  5. supprimer la trace de ses actions.

Réaliser une revue régulière des habilitations

Une revue des droits doit être réalisée à intervalles réguliers et lors des principaux changements :

  • arrivée d’un collaborateur ;

  • changement de poste ;

  • départ ;

  • changement d’entité ;

  • modification de l’organisation finance ;

  • ajout d’un nouveau logiciel ;

  • création d’un nouveau connecteur.

La revue doit couvrir les utilisateurs humains, mais aussi les comptes techniques et les intégrations.

Appréciez-vous ce que vous lisez ?

Nous publions de nouveaux articles comme celui-ci chaque semaine. Abonnez-vous à notre newsletter pour rester informé.

Une piste d’audit exploitable sert de preuve

Une piste d’audit permet de reconstituer le parcours d’une transaction, depuis sa création jusqu’à son export ou son paiement.

Elle doit notamment permettre de répondre aux questions suivantes :

  • Qui a créé la dépense ?

  • Qui l’a approuvée ?

  • Quand a-t-elle été modifiée ?

  • Quelle règle a orienté la transaction ?

  • Quel justificatif était associé ?

  • Quel compte comptable a été proposé ?

  • Qui a corrigé cette proposition ?

  • Quand l’écriture a-t-elle été exportée ?

  • Quel paiement correspond à la facture ?

La CNIL recommande de tracer les opérations sensibles, notamment l’auteur, la date, l’heure et la nature de l’action.

La durée de conservation des journaux techniques doit être définie en fonction de leur finalité, des risques, des obligations applicables et des recommandations de votre conseil. Elle ne doit pas être confondue avec la durée de conservation des pièces comptables.

Le FEC et les outils en amont

Lors d’un contrôle fiscal, le logiciel comptable doit pouvoir produire les fichiers requis, notamment le FEC lorsque celui-ci est demandé.

Les outils situés en amont du logiciel comptable doivent donc :

  • transmettre des données correctement mappées ;

  • préserver les justificatifs associés ;

  • conserver l’historique des validations ;

  • documenter les corrections ;

  • éviter les ruptures de traçabilité ;

  • permettre de retrouver l’origine d’une écriture.

Le FEC reste produit par le logiciel comptable. Une plateforme de gestion des dépenses ou de factures peut préparer et transmettre les données, mais elle ne remplace pas les contrôles du système comptable.

Les intégrations doivent être traitées comme des comptes à part entière

Un connecteur possède une identité, des autorisations et un périmètre d’accès.

Pour chaque intégration, documentez :

  • le nom du système ;

  • le responsable métier ;

  • le responsable technique ;

  • les données lues ;

  • les données écrites ;

  • les comptes ou entités concernés ;

  • les dates de création et de rotation des clés ;

  • les erreurs possibles ;

  • les alertes disponibles ;

  • la procédure de reprise.

Évitez les comptes techniques personnels. Si une intégration dépend du compte d’un salarié ou d’un prestataire externe, son départ peut interrompre la synchronisation.

Les clés et jetons doivent être :

  • conservés dans un emplacement sécurisé ;

  • limités au périmètre nécessaire ;

  • renouvelés selon une procédure définie ;

  • révoqués lorsqu’ils ne sont plus utilisés ;

  • associés à une alerte en cas d’échec.

Prévoir les échecs de synchronisation

Une intégration peut échouer pour plusieurs raisons :

  • identifiant expiré ;

  • modification du plan comptable ;

  • champ obligatoire manquant ;

  • indisponibilité temporaire ;

  • changement de format ;

  • erreur de mapping ;

  • dépassement d’un seuil ;

  • modification de l’API.

Un échec silencieux est particulièrement risqué. Il peut laisser une partie des dépenses ou des factures en dehors du logiciel comptable sans alerte visible.

Définissez donc :

  • qui reçoit l’alerte ;

  • dans quel délai elle doit être traitée ;

  • comment les données manquantes sont récupérées ;

  • comment l’incident est documenté ;

  • comment la synchronisation est vérifiée après correction.

Les sauvegardes doivent être isolées et testées

Une sauvegarde qui n’a jamais été restaurée n’est pas une garantie suffisante.

La CNIL recommande de protéger les sauvegardes, notamment en conservant des copies isolées du système principal et en testant régulièrement leur restauration.

Votre procédure doit préciser :

  • quelles données sont sauvegardées ;

  • à quelle fréquence ;

  • où les copies sont stockées ;

  • qui peut les supprimer ;

  • combien de temps elles sont conservées ;

  • combien de temps prend une restauration ;

  • comment l’intégrité des fichiers est vérifiée.

Les sauvegardes doivent couvrir les données, mais aussi les éléments nécessaires pour les exploiter :

  • justificatifs ;

  • journaux ;

  • paramétrages ;

  • mappings ;

  • historiques ;

  • workflows ;

  • référentiels fournisseurs ;

  • plans de comptes.

Réagir à une violation ou à une cyberattaque

Une attaque peut toucher les comptes utilisateurs, les intégrations, les postes de travail ou les sauvegardes.

La première étape consiste à limiter la propagation :

  • désactiver les comptes concernés ;

  • révoquer les clés et jetons ;

  • isoler les systèmes compromis ;

  • préserver les journaux ;

  • prévenir les responsables concernés ;

  • contacter l’éditeur ;

  • documenter les premières actions.

En cas de violation de données personnelles, la responsabilité de la notification dépend du rôle de l’organisation.

Le responsable de traitement doit déterminer si une notification à la CNIL est nécessaire et respecter le délai applicable. Le sous-traitant doit informer le responsable de traitement dans les meilleurs délais après avoir pris connaissance de la violation.

Consultez la documentation de la CNIL sur les violations de données personnelles et formalisez à l’avance les canaux de contact prévus avec votre éditeur.

La conservation des données doit être organisée

Les données comptables, les justificatifs, les journaux techniques et les données personnelles ne répondent pas nécessairement aux mêmes règles de conservation.

Séparez les catégories suivantes :

  • pièces comptables ;

  • documents fiscaux ;

  • justificatifs de dépenses ;

  • historiques de validation ;

  • journaux techniques ;

  • données de connexion ;

  • sauvegardes ;

  • données conservées après la fin du contrat.

Pour chaque catégorie, documentez :

  • la durée de conservation ;

  • la finalité ;

  • les personnes autorisées à y accéder ;

  • la méthode de suppression ;

  • les exceptions liées à un litige ou à un contrôle ;

  • la procédure de restitution.

La durée de conservation ne doit pas être choisie uniquement pour des raisons techniques. Elle doit correspondre à la finalité du traitement et aux obligations applicables.

Comment évaluer un éditeur avant d’automatiser ?

La sécurité se partage entre l’éditeur et l’entreprise cliente.

L’éditeur protège notamment son infrastructure, ses services et ses procédures internes. L’entreprise cliente configure les utilisateurs, les règles, les workflows, les intégrations et les accès à ses données.

Avant de signer, demandez des éléments vérifiables.

Domaine

Question à poser

Preuve à demander

Accès

L’authentification renforcée est-elle disponible pour les comptes sensibles ?

Documentation de configuration

Rôles

Peut-on séparer création fournisseur, modification d’IBAN et paiement ?

Matrice des rôles et démonstration

Journalisation

Les changements sont-ils horodatés avec leur auteur ?

Exemple anonymisé de journal

Export

Les données et justificatifs peuvent-ils être récupérés ?

Exemple de fichier d’export

Intégrations

Les clés sont-elles limitées, renouvelées et révoquées ?

Documentation et procédure

Incidents

Comment et dans quel délai les clients sont-ils alertés ?

Procédure et clause contractuelle

Sauvegardes

La restauration est-elle testée ?

Politique de sauvegarde et de reprise

Sous-traitants

Quels prestataires interviennent dans le traitement ?

Liste des sous-traitants

Réversibilité

Que deviennent les données en fin de contrat ?

Politique de restitution et de suppression

Certifications

Quel périmètre couvre chaque certification ?

Certificat et périmètre associé

Une certification peut constituer un indice utile, mais elle ne remplace pas l’analyse du périmètre exact du service, du contrat et des responsabilités de chacun.

Curieux de découvrir Spendesk ?

Essayez la plateforme avec une démo interactive pour voir la gestion des dépenses et approbations de bout en bout.

Voir la démo gratuite