Glossaire des tâches et contrôles du cabinet.

Confusion fréquenteUn agent est souvent confondu avec un assistant conversationnel : le second répond dans une fenêtre, le premier agit sur un environnement défini — applications tierces, bases de données, postes de travail — et en modifie l’état.

Exemple avec données fictivesDans un cabinet fictif, un agent lit une boîte de réception fictive, classe les messages par dossier et prépare un brouillon de réponse. L’envoi reste bloqué : aucun message ne part sans qu’un collaborateur l’ait ouvert et validé.

Ce qui reste à déciderEnchaîner des lectures, préparer un classement et rédiger une proposition est automatisable. Écrire dans un logiciel du cabinet ou envoyer un message reste soumis à une validation humaine explicite.

Confusion fréquenteConvention Memlia : nous ne déclarons jamais un export anonyme ou conforme au seul motif que ses lignes sont regroupées.

Exemple avec données fictives« 7 dossiers à contrôler » est affiché pour le pôle ; aucun nom, cadence ou score de gestionnaire n’apparaît.

Ce qui reste à déciderCalculer et afficher les comptes est automatisable ; définir la granularité, la finalité et les droits de lecture relève du cabinet.

Confusion fréquenteLes mêmes délais ne valent pas pour chaque déclaration ou signalement.

Exemple avec données fictivesUne variable oubliée est repérée sur un dossier fictif ; le gestionnaire confirme la correction puis choisit la déclaration adaptée.

Ce qui reste à déciderDétecter l’écart et préparer un dossier de correction est automatisable ; choisir, corriger et transmettre exige une validation.

Confusion fréquenteLes données pseudonymisées conservent un caractère personnel ; la pseudonymisation est réversible, contrairement à l’anonymisation.

Exemple avec données fictivesUn petit groupe avec un seul dossier atypique reste reconnaissable malgré l’absence de nom : l’export n’est pas déclaré anonyme.

Ce qui reste à déciderAppliquer des transformations et tester des seuils est automatisable ; qualifier juridiquement le résultat nécessite une revue humaine.

Confusion fréquenteL’automatisation est parfois confondue avec la numérisation, qui consiste seulement à remplacer le papier par un fichier, ou avec l’intelligence artificielle, qui infère un résultat au lieu de suivre une règle écrite d’avance.

Exemple avec données fictivesDans un cabinet fictif, le contrôle de cohérence entre le grand livre et un relevé bancaire est exécuté chaque semaine pour un jeu de dossiers tests. Les lignes qui correspondent exactement ne remontent nulle part ; celles qui diffèrent sont mises de côté pour un collaborateur fictif nommé pour l’exercice.

Ce qui reste à déciderExécuter la règle sur chaque occurrence et signaler les cas hors règle est automatisable. Écrire la règle, en fixer les limites et décider quoi faire des cas signalés restent des choix humains, revus à échéance régulière.

Confusion fréquenteL’automatisation robotisée est souvent confondue avec l’intelligence artificielle : elle rejoue une séquence de gestes décrite à l’avance et ne déduit rien du contenu qu’elle manipule.

Exemple avec données fictivesDans un cabinet fictif, une séquence recopie chaque semaine l’état de dix dossiers fictifs depuis un écran de suivi vers un classeur. Un bouton déplacé par une mise à jour l’arrête : elle s’interrompt et nomme l’écran qu’elle n’a pas reconnu, sans rien écrire.

Ce qui reste à déciderRejouer la séquence et s’arrêter dès qu’un écran ne correspond plus est automatisable. Décider qu’une application modifiée reste sûre à piloter, et à quelle cadence, reste une décision humaine.

Confusion fréquenteUn arrêt explicite est une protection du dossier, pas un échec à masquer.

Exemple avec données fictivesDeux feuilles portent le même nom attendu mais des structures différentes ; le traitement n’en choisit aucune.

Ce qui reste à déciderReconnaître une condition interdite et préparer le diagnostic est automatisable ; corriger ou élargir la règle reste humain.

Confusion fréquenteUn nom est souvent utilisé comme clé : une orthographe différente, un accent ou une raison sociale abrégée suffisent alors à casser le rapprochement, sans que rien ne signale la ligne manquée.

Exemple avec données fictivesSur un jeu fictif, deux écritures portent le même montant le même jour pour deux dossiers distincts. La clé retenue ajoute le numéro de dossier ; sans lui, les deux lignes se seraient rapprochées l’une de l’autre.

Ce qui reste à déciderAppliquer la clé, refuser les correspondances multiples et lister les lignes sans correspondance est automatisable. Choisir la clé, et trancher un cas à plusieurs candidats, reste un acte humain.

Confusion fréquenteLa complétude est parfois confondue avec le simple fait que le client a transmis un lot de documents ; un lot reçu peut très bien être incomplet au regard de la liste attendue pour la période.

Exemple avec données fictivesPour un dossier fictif, la liste attendue pour le mois comporte huit pièces ; sept sont reçues et lisibles, la huitième est un relevé bancaire flou. Le dossier est marqué incomplet jusqu’à réception d’un relevé lisible.

Ce qui reste à déciderComparer les pièces reçues à la liste attendue et signaler les manques est automatisable, à condition que la liste soit définie et tenue à jour. Décider qu’une pièce reçue est acceptable malgré un défaut mineur reste un jugement humain.

Confusion fréquenteConvention Memlia : même sans anomalie visible dans un retour, le cabinet conserve sa revue de paie.

Exemple avec données fictivesUn retour fictif signale un écart d’assiette ; la ligne est remontée pour revue, pas corrigée automatiquement.

Ce qui reste à déciderCollecter, classer et rapprocher le retour du dossier est automatisable ; la correction et sa fenêtre sont validées par le gestionnaire.

Confusion fréquenteL’absence d’API est souvent lue comme une impossibilité d’automatiser : l’export de fichier reste une voie praticable, plus fragile, à condition d’en vérifier le format à chaque passage.

Exemple avec données fictivesPour un cabinet fictif, un outil de suivi expose une porte qui rend la liste des dossiers ; un second n’en a pas et livre un fichier chaque nuit. Les deux alimentent le même tableau fictif, par deux voies distinctes.

Ce qui reste à déciderAppeler la porte, lire la réponse et refuser un format inattendu est automatisable. Obtenir les droits d’accès, accepter les conditions de l’éditeur et arbitrer entre deux voies restent humains.

Confusion fréquenteCe contrôle ne se réduit pas à DSN-Val et tout écart n’est pas nécessairement une erreur.

Exemple avec données fictivesUne variation de brut est signalée ; une prime annuelle documentée explique l’écart, qui est alors validé.

Ce qui reste à déciderComparer, tester et documenter sont automatisables ; qualifier l’écart, modifier la paie et déposer restent humains.

Confusion fréquenteTout signal n’est pas une erreur certaine et aucune correction ne doit être faite sans pièce ni contexte.

Exemple avec données fictivesLe total d’un tableau fictif diffère de la somme de ses lignes ; l’écart et les cellules concernées sont listés.

Ce qui reste à déciderRecalculer, comparer et classer les écarts est automatisable ; expliquer l’écart et décider de la correction reste humain.

Confusion fréquenteLe déclencheur est souvent confondu avec la règle qu’il lance : le déclencheur répond à « quand », la règle répond à « quoi faire ».

Exemple avec données fictivesDans un scénario fictif, la relance d’une pièce manquante se déclenche cinq jours ouvrés après l’échéance déclarée du dossier, jamais avant. Un autre déclencheur, la réception de la pièce, arrête la relance en cours.

Ce qui reste à déciderSurveiller la survenue du déclencheur et lancer la règle associée est automatisable. Choisir quel événement doit déclencher quelle règle, et à quelle fréquence, reste une décision du cabinet, revue quand la procédure change.

Confusion fréquenteRetirer le nom ne suffit pas toujours à sortir du champ du RGPD.

Exemple avec données fictivesUn tableau remplace les noms par des numéros, mais une table séparée permet de retrouver les personnes : les données restent personnelles.

Ce qui reste à déciderDétecter certains champs ou empêcher leur export peut être automatisé ; déterminer la finalité, la base et les accès exige une décision responsable.

Confusion fréquenteConvention Memlia : un fichier accepté techniquement reste soumis à la revue de paie du cabinet.

Exemple avec données fictivesPour un dossier fictif, le fichier du mois est contrôlé avant son dépôt ; aucun salarié réel n’est utilisé.

Ce qui reste à déciderL’automatisation peut préparer des contrôles et signaler des écarts ; le gestionnaire valide les corrections et le dépôt.

Confusion fréquenteConvention Memlia : la recherche des primes oubliées relève de la revue du bulletin, distincte du test DSN-Val.

Exemple avec données fictivesUn export fictif est refusé parce qu’une rubrique ne respecte pas la structure attendue.

Ce qui reste à déciderLancer le test et lire un résultat sont automatisables ; qualifier l’origine métier et corriger la paie relèvent du gestionnaire.

Confusion fréquenteUne exception est parfois prise pour un bug à corriger dans l’outil ; elle signale au contraire que la règle a correctement reconnu ses propres limites plutôt que de produire un résultat non fiable.

Exemple avec données fictivesDans un jeu de test fictif, une facture sans numéro de TVA sort du traitement automatique et remonte avec le motif exact du refus. Un collaborateur fictif la complète ou la renvoie à l’émetteur, selon le cas.

Ce qui reste à déciderDétecter qu’un cas sort de la règle et le signaler avec un motif explicite est automatisable. Décider quoi faire de ce cas — corriger, écarter, faire remonter au client — reste une décision humaine.

Confusion fréquenteUn export est souvent pris pour une copie stable : chaque ligne d’un même fichier doit porter le même nombre de champs, et rien n’oblige un éditeur à conserver ses colonnes d’une version à l’autre.

Exemple avec données fictivesSur un export fictif, une colonne attendue manque. L’import s’arrête, nomme la colonne absente et n’écrit aucune ligne, plutôt que de décaler les valeurs suivantes d’un rang.

Ce qui reste à déciderVérifier l’en-tête, compter les champs et refuser un fichier non conforme est automatisable. Décider d’accepter une nouvelle colonne, ou de réécrire la règle de lecture, reste une décision humaine.

Confusion fréquenteL’OCR reconnaît des caractères dans une image ; l’extraction identifie les champs utiles. Les deux peuvent être combinés, mais l’extraction peut aussi utiliser du texte natif ou un flux structuré.

Exemple avec données fictivesSur une facture fictive, l’extraction identifie correctement le montant et la date, mais place par erreur le numéro de commande dans le champ réservé au numéro de facture. L’écart est signalé avant toute intégration comptable.

Ce qui reste à déciderRepérer un champ selon un schéma stable et connu est automatisable. Traiter un document dont la mise en page ne correspond à aucun schéma prévu doit être signalé pour une vérification humaine plutôt que deviné.

Confusion fréquenteRemplacer un champ absent par zéro, deviner une feuille ou poursuivre silencieusement fabrique un résultat non fiable.

Exemple avec données fictivesUne colonne obligatoire manque dans un export fictif ; aucun rapprochement n’est produit et le diagnostic nomme la colonne attendue.

Ce qui reste à déciderArrêter et diagnostiquer selon des conditions codées est automatisable ; corriger l’entrée ou changer la règle demande validation.

Confusion fréquenteUne file d’anomalies est parfois confondue avec une alerte envoyée par courriel à chaque cas : la file regroupe et hiérarchise, l’alerte au fil de l’eau disperse l’attention et noie les cas urgents dans les cas mineurs.

Exemple avec données fictivesPour un exercice fictif, sept lignes s’accumulent dans la file sur une semaine : trois montants incohérents, deux pièces illisibles, deux dates manquantes. Un collaborateur fictif les traite en une session, referme celles qui sont réglées et laisse les autres en attente.

Ce qui reste à déciderDétecter chaque anomalie, la qualifier et l’ajouter à la file est automatisable. Décider de l’ordre de traitement et trancher chaque cas reste une tâche humaine, à une cadence choisie par le cabinet.

Confusion fréquenteUn flux de travail est parfois pris pour le logiciel qui l’exécute ; il existait pourtant sur papier ou dans une tête avant tout outil, et continue d’exister si l’outil change.

Exemple avec données fictivesPour un dossier fictif, le flux de relance de pièces comporte quatre étapes : identifier la pièce manquante, relancer le client, réceptionner la pièce, classer le dossier comme complet. Chaque étape a un responsable désigné, même quand aucune n’est encore automatisée.

Ce qui reste à déciderDocumenter les étapes et exécuter celles qui suivent une règle stable est automatisable. Décider de l’ordre des étapes, du responsable de chacune et de ce qui justifie une exception reste une décision du cabinet.

Confusion fréquenteCette technique est souvent prise pour une garantie d’exactitude : elle borne ce que le modèle peut invoquer, sans empêcher une lecture fautive du passage retenu ni le choix d’un document inadapté.

Exemple avec données fictivesSur un corpus fictif de notes internes, une question sur une règle de calcul rend la réponse accompagnée du paragraphe d’où elle est tirée. Sans paragraphe rattaché, la réponse est refusée plutôt que produite.

Ce qui reste à déciderRechercher les passages pertinents, les fournir au modèle et afficher la citation est automatisable. Vérifier que le passage cité dit bien ce que la réponse affirme reste une lecture humaine.

Confusion fréquenteUn grand modèle de langage est parfois pris pour une base de connaissances à jour ; il prédit un texte plausible à partir de ce qu’il a appris à l’entraînement, sans consulter une source actuelle sauf si l’outil qui l’utilise le prévoit explicitement.

Exemple avec données fictivesDans un cas fictif, un modèle de langage propose une reformulation d’un courrier de relance rédigé pour un client fictif, sans connaître les échanges antérieurs propres à ce dossier. Un collaborateur fictif vérifie que la reformulation correspond bien au dossier avant envoi.

Ce qui reste à déciderGénérer une suite de texte plausible à partir d’une consigne est ce que le modèle fait par construction. Vérifier l’exactitude de ce texte pour le dossier précis et décider de son usage restent des étapes humaines.

Confusion fréquenteUne hallucination est parfois prise pour un bug ponctuel réparable par une mise à jour ; c’est en réalité une propriété du fonctionnement probabiliste de ces systèmes, qui ne disparaît pas complètement, mais peut être réduite.

Exemple avec données fictivesDans un test fictif, un outil génératif attribue à un texte réglementaire un numéro d’article qui n’existe pas, formulé avec la même assurance que le reste de sa réponse. Seule la vérification par un collaborateur fictif révèle l’erreur.

Ce qui reste à déciderPrivilégier des systèmes qui citent leurs sources ou filtrent leurs résultats réduit le risque, et cela s’automatise. Vérifier l’exactitude d’un résultat précis avant de l’utiliser reste, dans tous les cas, une étape humaine.

Confusion fréquenteL’erreur la plus fréquente est de facturer en acte hors forfait une prestation déjà comprise dans le forfait mensualisé, ce qui revient à facturer deux fois le même travail.

Exemple avec données fictivesPour un client fictif, le forfait mensuel couvre la tenue et la paie courante ; une attestation ponctuelle demandée en cours d’année est facturée à part, en acte hors forfait, sur la base d’un tarif fictif communiqué au préalable.

Ce qui reste à déciderVérifier qu’un acte facturé hors forfait n’apparaît pas déjà dans le périmètre du forfait est automatisable, à condition que ce périmètre soit décrit avec précision. Fixer le tarif d’un acte hors forfait et le proposer au client restent des décisions humaines.

Confusion fréquenteUn moteur de recherche retrouve des contenus ; un système génératif produit une sortie, éventuellement à partir de contenus retrouvés. Cette sortie peut reprendre une formulation existante et doit être vérifiée.

Exemple avec données fictivesDans un test fictif, un brouillon de courrier de relance est rédigé par un outil génératif à partir de trois informations : le nom du dossier fictif, l’échéance et la pièce manquante. Un collaborateur fictif relit le brouillon avant tout envoi.

Ce qui reste à déciderProduire un brouillon à partir d’une consigne stable est automatisable. Relire ce brouillon, corriger ce qu’il contient et décider de l’envoyer restent des étapes humaines, quel que soit le soin apporté à la consigne.

Confusion fréquenteL’idempotence est souvent prise pour une annulation : elle ne défait rien et ne rattrape aucune erreur, elle garantit seulement qu’un second passage ne modifie pas l’état obtenu au premier.

Exemple avec données fictivesSur un jeu d’essai fictif, le même relevé est importé deux fois de suite. Le second passage ne crée aucune écriture et rend le nombre de lignes déjà présentes, que le collaborateur compare à celui du premier import.

Ce qui reste à déciderReconnaître qu’une ligne existe déjà et refuser de la réécrire est automatisable, à condition qu’une clé stable la désigne. Choisir cette clé et trancher qu’un doublon apparent en est un reste humain.

Confusion fréquenteUn jeu d’essai fictif est parfois pris pour un jeu de données anonymisées : l’anonymisation part de données réelles et cherche à empêcher la réidentification, alors que le jeu fictif n’a jamais correspondu à une personne existante.

Exemple avec données fictivesUn jeu fictif comporte par exemple douze salariés inventés, aux noms manifestement fictifs, dont les bulletins couvrent un temps plein, un temps partiel et un contrat rompu en cours de mois. Aucun de ces salariés ne correspond à une personne réelle.

Ce qui reste à déciderGénérer des variantes du jeu fictif pour couvrir de nouveaux cas est automatisable une fois le jeu initial construit. Décider quels cas limites et quels cas de refus le jeu doit couvrir reste un choix humain, propre à chaque traitement.

Confusion fréquenteIl ne faut pas forcer un lettrage pour faire disparaître un écart ni associer des montants sans vérifier les pièces.

Exemple avec données fictivesUne facture fictive de 600 € et un règlement fictif de 600 € reçoivent le même repère ; un avoir non affecté reste ouvert.

Ce qui reste à déciderProposer des correspondances exactes ou plausibles est automatisable ; confirmer une affectation ambiguë ou un solde litigieux reste humain.

Confusion fréquenteLa finalité du traitement détermine quelles données sont nécessaires ; une colonne sans nécessité au regard de cette finalité est exclue.

Exemple avec données fictivesLa vue affiche trois dossiers en attente, sans nom de gestionnaire ni temps passé.

Ce qui reste à déciderBloquer des champs interdits et produire une vue agrégée est automatisable ; fixer la finalité et décider ce qui est nécessaire reste humain.

Confusion fréquenteUn modèle local est souvent confondu avec un service « hébergé en France » : un service distant, même installé en France, reçoit bien les documents, et la réutilisation possible par le prestataire qui l’opère reste à établir.

Exemple avec données fictivesDans un cabinet fictif, un modèle installé sur un poste dédié résume des pièces fictives sans connexion sortante. Le même travail confié à un service distant sortirait les pièces du parc, ce qui change la question posée.

Ce qui reste à déciderLes contrôles réseau peuvent vérifier les flux prévus dans un environnement donné. Autoriser les accès, choisir les pièces soumises et accepter le mode de déploiement restent des décisions du cabinet.

Confusion fréquenteUn montant saisi, une capture sans origine ou un commentaire libre ne constitue pas toujours une preuve suffisante.

Exemple avec données fictivesUne dépense fictive reste « à revoir » car le libellé bancaire existe, mais la facture correspondante manque.

Ce qui reste à déciderVérifier présence, format, date ou doublon est automatisable ; juger l’adéquation de la pièce et la traiter relève du professionnel.

Confusion fréquenteUne proposition d’imputation ou d’écriture n’est pas une écriture validée. La pré-comptabilité prépare le contrôle ; elle ne remplace pas la tenue comptable ni sa validation.

Exemple avec données fictivesPour un dossier fictif, les pièces d’un mois sont d’abord triées par nature — achats, ventes, banque — avant tout début de saisie. Une pièce illisible est mise de côté et signalée plutôt que saisie approximativement.

Ce qui reste à déciderCollecter, extraire, préparer une proposition selon la règle du cabinet et signaler les pièces incertaines est automatisable. Décider de l’imputation définitive et valider l’écriture restent au cabinet.

Confusion fréquenteUn rejet de prélèvement est parfois pris pour un impayé acté ; la plupart des rejets se résolvent par une nouvelle présentation ou un rappel, et ne devraient être traités comme un impayé qu’après plusieurs échecs.

Exemple avec données fictivesPour un cabinet fictif, un prélèvement du mois est rejeté pour provision insuffisante ; une nouvelle présentation est programmée dix jours plus tard, avec un message informant le client fictif du rejet et de sa cause.

Ce qui reste à déciderDétecter un rejet, en lire le motif codé et programmer une nouvelle présentation selon une règle fixée est automatisable. Décider de contacter directement un client après plusieurs rejets successifs reste une décision humaine.

Confusion fréquenteLa production sociale n’est ni le logiciel de paie ni une mesure de productivité individuelle.

Exemple avec données fictivesUne vue agrège les dossiers fictifs « pièces reçues », « contrôlés » et « déposés » pour le mois.

Ce qui reste à déciderMettre à jour les états, calculer des agrégats et signaler les exceptions est automatisable ; relancer ou valider un dépôt reste humain.

Confusion fréquenteCe principe est parfois confondu avec « l’outil fait tout, puis on vérifie après coup » : la validation intervient avant l’effet, jamais en rattrapage d’un résultat déjà produit.

Exemple avec données fictivesDans un scénario fictif, un rapprochement bancaire propose une correspondance entre une ligne de relevé et une facture ; elle reste en attente jusqu’à ce qu’un collaborateur fictif confirme ou corrige l’affectation proposée. Rien n’est comptabilisé avant cette confirmation.

Ce qui reste à déciderPréparer la proposition à partir d’une règle et consigner la décision prise est automatisable. Porter le jugement sur le cas précis et l’autoriser reste, par construction, une étape humaine.

Confusion fréquenteLa pseudonymisation n’est ni une anonymisation ni une sortie du RGPD.

Exemple avec données fictivesLa vue utilise « DOS-017 » et la table de correspondance est isolée avec des droits plus stricts.

Ce qui reste à déciderRemplacer les identifiants et séparer les tables est automatisable ; choisir les accès, la conservation et l’usage reste une responsabilité humaine.

Confusion fréquenteUne écriture ne doit pas être modifiée uniquement pour forcer l’égalité des soldes.

Exemple avec données fictivesUn virement fictif comptabilisé le 30 apparaît sur le relevé le 2 du mois suivant ; l’écart est daté, pas supprimé.

Ce qui reste à déciderImporter, rapprocher des références et lister les écarts est automatisable ; justifier l’écart et passer une écriture restent soumis à validation.

Confusion fréquenteLa recette est parfois confondue avec une démonstration : la démonstration montre un cas favorable choisi à l’avance, la recette confronte le livrable aux cas propres du cabinet, y compris ceux qui doivent échouer.

Exemple avec données fictivesPour un traitement fictif, la recette rejoue douze dossiers inventés : huit cas courants, trois cas limites, un cas volontairement refusé pour vérifier que le refus est bien signalé. Le cabinet fictif valide le livrable seulement après avoir examiné les douze résultats.

Ce qui reste à déciderPréparer le jeu de cas et comparer un résultat attendu à un résultat obtenu est automatisable. Décider si l’écart constaté est acceptable, et accepter le livrable, reste une décision du cabinet.

Confusion fréquenteL’OCR est parfois prise pour de la compréhension du document ; elle restitue des caractères sans savoir lequel est un montant, une date ou un nom, ce que fait l’étape d’extraction qui suit.

Exemple avec données fictivesSur un ticket de caisse fictif légèrement froissé, l’OCR restitue correctement le montant total mais bute sur le nom du commerçant, imprimé trop pâle. Le champ douteux est signalé plutôt que deviné.

Ce qui reste à déciderConvertir une image en texte brut est entièrement automatisable et constitue la fonction même de l’OCR. Juger de la fiabilité d’une lecture douteuse — caractère peu net, document froissé — reste une vérification humaine avant usage.

Confusion fréquenteConvention Memlia : un simple retard ne doit pas déclencher automatiquement un envoi. Une relance précède généralement la mise en demeure en cas d’échec ; ce sont deux étapes distinctes.

Exemple avec données fictivesUn statut « déjà payé » bloque une relance préparée ; la personne contrôle le relevé avant de décider.

Ce qui reste à déciderDétecter les retards et préparer une proposition de message est automatisable ; décider du ton, du destinataire et envoyer reste humain.

Confusion fréquenteUne habitude orale ambiguë ne doit pas devenir un automatisme sans validation de son périmètre.

Exemple avec données fictives« Signaler toute ligne sans référence de pièce, sauf les écritures d’ouverture identifiées. »

Ce qui reste à déciderExécuter une règle stabilisée est automatisable ; choisir la règle, ses exceptions et sa version reste une décision du cabinet.

Confusion fréquenteLa relance de pièces est souvent confondue avec la relance d’impayés ; l’une réclame un document nécessaire à une mission, l’autre réclame une somme due, avec un ton et des conséquences très différents.

Exemple avec données fictivesPour un dossier fictif, un brouillon à sept jours puis un autre à quatorze jours sont proposés selon la cadence d’essai. Chaque envoi attend une validation ; la réception d’un relevé lisible arrête la préparation suivante.

Ce qui reste à déciderIdentifier les pièces manquantes, préparer le rappel selon la cadence et arrêter sa préparation à réception est automatisable. L’envoi attend une validation humaine ; le cabinet décide du contenu et des dérogations.

Confusion fréquenteUn reliquat est souvent lu comme un taux d’erreur : le premier est attendu et dimensionné dès l’écriture de la règle, le second est un défaut à corriger.

Exemple avec données fictivesSur un jeu fictif de deux cents lignes, cent quatre-vingt-douze sont traitées et huit remontent : six pièces illisibles et deux montants sans correspondance. Le chiffre huit est affiché à côté du total, jamais masqué.

Ce qui reste à déciderCompter les cas écartés, les classer par motif et les présenter est automatisable. Traiter chaque cas remonté, et décider si leur nombre justifie de réécrire la règle, revient au cabinet.

Confusion fréquenteUne checklist générique ne remplace pas les diligences adaptées à la mission et la révision n’est pas la certification des comptes.

Exemple avec données fictivesUn cycle fournisseurs fictif comporte soldes anciens, doublons possibles et pièces manquantes ; chaque point reçoit preuve, conclusion ou demande de revue.

Ce qui reste à déciderExécuter des tests définis et préparer le dossier est automatisable ; fixer les diligences et conclure reste au professionnel.

Confusion fréquenteDeux fichiers ne sont pas compatibles simplement parce que leurs colonnes se ressemblent visuellement.

Exemple avec données fictivesLa colonne « date_piece » exige une date valide, « montant » un nombre décimal et « reference » une chaîne non vide.

Ce qui reste à déciderValider types, champs et formats est automatisable ; décider du sens métier d’une colonne et faire évoluer le contrat reste humain.

Confusion fréquenteUn seuil d’alerte est parfois pris pour une tolérance comptable : il décide de ce qui remonte à un humain, jamais de ce qui est régulier, exact ou acceptable en comptabilité.

Exemple avec données fictivesPour un dossier fictif, un écart de plus de cinquante euros ou de plus de cinq pour cent entre deux relevés remonte. Sous ces deux valeurs, la ligne est classée sans mention, et le seuil retenu reste affiché.

Ce qui reste à déciderAppliquer le seuil, compter ce qu’il écarte et l’afficher est automatisable. Fixer sa valeur, la réviser et assumer ce qu’elle laisse passer restent des décisions du cabinet.

Confusion fréquenteLe titre de fournisseur, d’éditeur ou de cabinet ne suffit pas à fixer un rôle RGPD. Recevoir des données ne fait pas automatiquement d’un organisme un sous-traitant : il faut examiner le traitement et qui en détermine les finalités et les moyens.

Exemple avec données fictivesDans un cas fictif, un cabinet détermine les finalités et les moyens de sa messagerie interne. Un hébergeur traite les messages pour son compte et selon ses instructions : ce traitement est encadré par un contrat de sous-traitance.

Ce qui reste à déciderRecenser les outils qui traitent des données personnelles pour signaler ceux à qualifier est automatisable. Qualifier juridiquement chaque cas et négocier les clauses contractuelles requises restent des tâches humaines, en général avec un conseil compétent.

Confusion fréquenteUn système d’IA est parfois confondu avec n’importe quel logiciel automatisé ; le règlement réserve la qualification aux systèmes qui déduisent leurs sorties à partir des entrées reçues, et exclut ceux qui appliquent des règles définies uniquement par des personnes.

Exemple avec données fictivesPour un outil fictif de tri de courriels, la qualification de système d’IA dépend de la façon dont il classe les messages : une liste de mots-clés fixée à l’avance ne suffit pas à en faire un, un modèle qui infère la catégorie à partir d’exemples peut en faire un.

Ce qui reste à déciderRien dans cette définition ne s’automatise : elle sert à qualifier juridiquement un outil, pas à faire fonctionner un traitement. La qualification d’un outil précis reste un examen à mener au cas par cas, en général avec un conseil compétent.

Confusion fréquenteLa traçabilité n’est ni une surveillance nominative ni une conservation illimitée de chaque action.

Exemple avec données fictivesUn rapport fictif indique la version de règle, l’horodatage, les contrôles exécutés et les lignes refusées.

Ce qui reste à déciderJournaliser les étapes techniques prévues est automatisable ; choisir les événements, accès et durées de conservation reste humain.

Confusion fréquenteUn clic automatique, une absence de réponse ou un écran sans éléments de preuve n’est pas une validation.

Exemple avec données fictivesUne correspondance bancaire proposée reste en attente jusqu’à ce qu’un collaborateur vérifie la pièce et confirme l’affectation.

Ce qui reste à déciderPréparer le dossier de décision et consigner le choix est automatisable ; porter le jugement et l’autoriser reste humain.