Progiciels et PGI : paramétrage, flux de travail et traçabilité des opérations

Exemples corrigés

Cas 1 : les paramètres à revoir après trois changements

Énoncé. Une société de négoce utilise un PGI. Trois événements surviennent :

• A. Elle ouvre un nouvel exercice comptable.
• B. Elle commence à acheter à un fournisseur établi dans un autre pays de l'Union européenne.
• C. La direction décide qu'une facture fournisseur supérieure à 1 000 € HT devra désormais être validée par la direction financière en plus du responsable de service (règle interne fictive de l'énoncé).

Pour chaque événement, indiquer les paramètres à vérifier, modifier ou mettre en œuvre, et l'effet attendu.

Corrigé.

Le point C montre le lien entre paramétrage et droits (cours 22) : sans le droit de validation attribué à la direction financière, l'étape paramétrée serait impossible à franchir. Inversement, un droit accordé sans le circuit paramétré laisserait passer la facture sans la seconde validation.

Conclusion.

À retenir

Les trois changements se traduisent par trois séries de paramètres, dont deux sont des créations et un seul une modification. Le plus risqué est le paramétrage fiscal du fournisseur étranger : une erreur sur le code de TVA se répète sur chaque facture et n'apparaît qu'à la déclaration. Je recommande de tester chaque nouveau paramètre sur une opération fictive avant de l'ouvrir aux utilisateurs, et de faire vérifier le code de TVA par le responsable fiscal.

Cas 2 : interpréter le circuit de validation d'une facture fournisseur

Énoncé. Le flux de travail de la société (règles de l'énoncé) est le suivant :

• R1. Le comptable fournisseurs saisit la facture (état « Saisie »).
• R2. Le progiciel contrôle automatiquement la concordance avec la commande et la réception. Si elles concordent, la facture passe à l'état « En validation » ; sinon elle passe à l'état « En anomalie » et retourne à l'acheteur.
• R3. Une facture inférieure ou égale à 1 000 € HT est validée par le responsable de service (état « Validée »).
• R4. Une facture supérieure à 1 000 € HT est validée par le responsable de service (« Validée niveau 1 »), puis par la direction financière (« Validée niveau 2 »).
• R5. Le comptable fournisseurs ne peut payer qu'une facture à l'état « Validée » ou « Validée niveau 2 ». Il ne peut jamais valider.
• R6. Si un valideur n'a pas répondu après trois jours ouvrés, le progiciel le relance automatiquement.

Trois factures sont saisies : A de 480 € HT (concordante), B de 2 350 € HT (concordante), C de 1 200 € HT (la réception enregistrée ne couvre que 900 €).

1. Décrire le parcours de chaque facture.
2. Que se passe-t-il si le responsable de service est absent pendant quatre jours ouvrés ?
3. Quelle contribution ce flux apporte-t-il à la qualité du processus ?

Corrigé.

1. Parcours.

1. La relance automatique (R6) rappelle le responsable après trois jours ouvrés ; le progiciel ne laisse pas la facture en attente sans signal. Le flux ne prévoit pas de remplaçant : si l'absence se prolonge, la facture reste en « En validation ». Le candidat peut recommander de paramétrer un suppléant ou une délégation.

2. Contributions : délai (transmission immédiate, relance), fiabilité (rapprochement automatique : la facture C est bloquée avant tout paiement), conformité (la règle de seuil s'applique à toutes les factures), séparation des tâches (le comptable ne valide jamais, R5), traçabilité (chaque changement d'état est horodaté et rattaché à un utilisateur).

Conclusion.

À retenir

Le circuit protège la société sur deux points : aucune facture n'est payée sans rapprochement ni validation, et le comptable qui paie n'est pas celui qui valide. Il reste un point faible : il n'y a pas de suppléant, donc l'absence d'un valideur bloque le paiement. Je recommande de paramétrer un remplaçant par valideur et de mesurer chaque mois le délai moyen entre la saisie et la validation.

Cas 3 : exploiter le journal des événements

Énoncé. À la clôture, le contrôle interne examine le journal du circuit de validation du cas 2 pour le mois de mars. La société précise que le travail a lieu de 8 h à 19 h (règle interne fictive). Le journal contient notamment les événements suivants (une ligne par événement).

La table FACTURE contient le montant courant de chaque facture.

1. Retracer l'historique de la facture F-101.
2. Repérer les factures saisies et validées par la même personne.
3. Repérer les modifications faites après validation.
4. Repérer les factures supérieures à 1 000 € payées sans validation par la direction financière.
5. Examiner les événements en dehors des horaires de travail.
6. Rédiger une note de synthèse.

Corrigé.

1. Le journal d'une pièce se lit en filtrant sur la référence et en triant par date.

SELECT DateHeure, Utilisateur, Operation, Champ, Ancienne, Nouvelle
FROM JOURNAL
WHERE Reference = 'F-101'
ORDER BY DateHeure;

La facture a été saisie à 480 €, validée, modifiée à 840 € après validation, puis payée.

1. Pour détecter une saisie et une validation par la même personne, on rapproche le journal avec lui-même (jointure réflexive, cours 16) : même pièce, même utilisateur, une création d'un côté, une validation de l'autre.

SELECT C.Reference, C.Utilisateur, C.Role
FROM JOURNAL C INNER JOIN JOURNAL V
     ON V.Reference = C.Reference AND V.Utilisateur = C.Utilisateur
WHERE C.Operation = 'CREATION' AND V.Operation = 'VALIDATION'
ORDER BY C.Reference;

La facture F-103 a été saisie et validée par le comptable fournisseurs : c'est une violation directe de la règle R5, qui interdit au comptable de valider.

1. Une modification est suspecte si une validation de la même pièce l'a précédée.

SELECT M.Reference, M.DateHeure, M.Utilisateur, M.Ancienne, M.Nouvelle
FROM JOURNAL M
WHERE M.Operation = 'MODIFICATION'
  AND EXISTS (SELECT * FROM JOURNAL V
              WHERE V.Reference = M.Reference
                AND V.Operation = 'VALIDATION'
                AND V.DateHeure < M.DateHeure)
ORDER BY M.DateHeure;

La facture F-101, validée à 480 €, a été portée à 840 € par la suite, soit une hausse de 75 % sans nouvelle validation. L'acteur est le responsable de service ; or aucune règle du circuit ne prévoit qu'une pièce déjà validée puisse être modifiée.

1. Les factures de plus de 1 000 € HT sont déjà payées ; on cherche celles qui n'ont pas de validation de la direction financière.

SELECT F.Reference, F.Fournisseur, F.Montant
FROM FACTURE F
WHERE F.Montant > 1000
  AND EXISTS (SELECT * FROM JOURNAL P
              WHERE P.Reference = F.Reference AND P.Operation = 'PAIEMENT')
  AND NOT EXISTS (SELECT * FROM JOURNAL D
                  WHERE D.Reference = F.Reference
                    AND D.Operation = 'VALIDATION'
                    AND D.Role = 'Direction financière')
ORDER BY F.Reference;

La facture F-103 (1 200 €) a été payée sans validation de niveau 2, contrairement à la règle R4. La facture F-102, supérieure au seuil, a bien franchi les deux niveaux.

1. Pour les horaires, on extrait l'heure du texte de la date et on retient les événements avant 8 h ou à partir de 19 h.

SELECT NumEvt, DateHeure, Utilisateur, Operation, Reference, Resultat
FROM JOURNAL
WHERE SUBSTRING(DateHeure FROM 12 FOR 2) >= '19'
   OR SUBSTRING(DateHeure FROM 12 FOR 2) < '08'
ORDER BY NumEvt;

Le responsable de service s'est connecté à 19 h 46 après deux échecs, puis a modifié le montant de la facture F-101 à 19 h 47. Les deux échecs de connexion suivis d'un succès peuvent simplement traduire un mot de passe oublié.

Synthèse.

À retenir

Note au directeur financier. Le journal de mars révèle des écarts sur deux des trois factures. La facture F-103 (1 200 €) a été saisie, validée et payée par la même personne, le comptable fournisseurs : la règle qui lui interdit de valider (R5) n'a pas été respectée, et le deuxième niveau de validation exigé au-dessus de 1 000 € (R4) a été sauté. La facture F-101 a été portée de 480 € à 840 € après sa validation, en soirée, puis payée au montant modifié. Ces constats sont des indices : ils ne prouvent ni l'intention ni la fraude, mais ils justifient une vérification auprès des personnes concernées et des fournisseurs. Je recommande de retirer au comptable fournisseurs tout droit de validation, de verrouiller la modification d'une pièce validée (ou de la soumettre à une nouvelle validation), de bloquer le paiement sans validation de niveau 2 au-dessus du seuil, et d'examiner régulièrement le journal avec les requêtes ci-dessus.

Vocabulaire essentiel

Points clés à retenir

1. Un PGI s'appuie sur une base de données unique et des modules intégrés : une information, une saisie.
2. Paramétrer : renseigner les règles de fonctionnement (TVA, utilisateurs, circuits, exercice) sans programmer.
3. Un mauvais paramètre se répercute sur toutes les opérations suivantes.
4. Le flux de travail fait circuler un document selon des règles (montant, acteur, délai) ; le candidat l'interprète, il ne le modélise pas.
5. Un bon circuit de validation applique la séparation des tâches, interdit le paiement avant validation et prévoit le rejet.
6. La traçabilité repose sur un journal complet, fiable, intègre, conservé et protégé.
7. Exploiter une trace : question, extraction, rapprochement avec les règles et les droits, écarts, conclusion nuancée, recommandation.
8. Une trace est un indice, pas une preuve d'intention.

Pièges fréquents

1. Confondre PGI et simple logiciel de comptabilité : le PGI intègre plusieurs fonctions sur une base unique.
2. Oublier le lien paramétrage et droits : une étape paramétrée sans droit correspondant est inopérante.
3. Modéliser le flux de travail alors que seule son interprétation est demandée.
4. Suivre une règle sans tenir compte du montant : le seuil détermine le circuit.
5. Conclure à la fraude à partir d'une trace : elle ne justifie qu'une vérification.
6. Oublier la séparation des tâches : celui qui saisit ne valide ni ne paie.
7. Négliger la protection du journal : il contient des données personnelles.
8. Citer un progiciel du marché : le sujet n'en nomme aucun, la réponse non plus.

Q&R pour le tuteur IA

Q : Qu'est-ce qui distingue un PGI d'un ensemble de logiciels séparés ? R : La base de données unique et l'intégration des modules : une information saisie dans un module est immédiatement disponible dans les autres, sans ressaisie.

Q : Qu'est-ce que le paramétrage d'un progiciel ? R : Le renseignement des choix de fonctionnement propres à l'organisation (plan de comptes, codes de TVA, utilisateurs et droits, circuits de validation), sans écrire de programme.

Q : Qu'est-ce qu'un flux de travail ? R : L'automatisation de la circulation d'un document ou d'une tâche entre plusieurs acteurs selon des règles : à qui transmettre, sous quelles conditions, dans quel délai.

Q : Faut-il modéliser un flux de travail à l'examen ? R : Non. Le programme demande de l'interpréter et de le mettre en œuvre dans le progiciel, pas de le modéliser.

Q : Que contient une trace d'opération ? R : L'identifiant de l'utilisateur, la date et l'heure, le type d'opération, l'objet concerné, les valeurs avant et après, et le résultat.

Q : Comment exploiter un journal pour détecter une anomalie ? R : On formule la question, on extrait les lignes pertinentes, on les compare aux règles du circuit et aux droits attribués, on repère les écarts (saisie et validation par la même personne, modification après validation) et on conclut avec nuance en recommandant une vérification.

Q : Une anomalie dans le journal prouve-t-elle une fraude ? R : Non. Elle constitue un indice qui justifie une vérification : le même écart peut résulter d'une erreur ou d'un défaut de paramétrage.