Ce qui est réalisé
Lecture de plusieurs présentations de relevés, synthèse filtrable et export CSV de la sélection.
Contrôles des pièces, lien vers les PDF et texte source conservé.
Alerte SMTP et planification Windows quotidienne documentées.
Automatiser l’administratif / Logigramme fonctionnel
Synthèse des extraits et alertes de complétude
Disposer d'une lecture transversale des relevés bancaires et repérer les pièces manquantes avant les travaux de rapprochement ou de clôture.
Le besoin
Disposer d'une lecture transversale des relevés bancaires et repérer les pièces manquantes avant les travaux de rapprochement ou de clôture.
L’analyse
Le classement de fichiers ne suffit pas à garantir qu'une période bancaire est complète. L'analyse croise trois indices : numérotation des extraits, continuité des soldes et ancienneté du dernier document. Les cartes suivent une cadence mensuelle spécifique, alors qu'un compte peut légitimement ne pas produire d'extrait pendant une période sans mouvement.
Le rapport combine exploration et contrôle : les filtres permettent de retrouver une opération, les liens remontent au PDF et les anomalies conduisent vers les pièces à récupérer. L'alerte quotidienne traduit les écarts en action tout en limitant les messages répétés. Le résultat est une base de travail documentaire, sans assimilation du total des mouvements au chiffre d'affaires ou aux dépenses consolidées.
Le processus documenté
Du besoin au résultat
Logigramme fonctionnelRègles de gestion
Ce que l’outil doit respecter.
- RG-01Le compte et le produit sont identifiés à partir de l'en-tête du PDF ; deux produits partageant un IBAN restent distincts.
- RG-02Les copies strictement identiques sont écartées ; les documents originaux ne sont pas modifiés.
- RG-03Les comptes sont contrôlés par séquence annuelle, continuité des soldes et seuil d'ancienneté configurable.
- RG-04Une clôture renseignée arrête les rappels ultérieurs sans effacer les trous historiques.
- RG-05Un nouveau scan reste à vérifier et une lecture impossible ne devient jamais un relevé vide.
- RG-06Une même anomalie déclenche au maximum une alerte par jour ; un envoi échoué peut être retenté et un retour à jour produit un message.
Ce que ce projet démontre.
Définition de règles de complétude différentes pour les comptes bancaires et les cartes.
Conception d'une traçabilité de l'opération structurée vers le texte source et le document.
Cadrage de l'alerte, de son anti-doublon et des limites de preuve d'une période complète.
Le niveau de réalisation ci-dessous distingue les fonctions présentes des vérifications qui restent à mener.
État au 13 octobre 2026
Une réalisation, un périmètre précis.
Ce qui a été vérifié
Le README rapporte le rapprochement des soldes et opérations des relevés bancaires disponibles, une vérification visuelle des relevés de carte, l'acceptation SMTP d'une première alerte et un test réussi de la tâche Windows le 2 octobre.
Limites actuelles
L'acceptation SMTP ne prouve pas la réception dans la boîte. Le fonctionnement actuel de la tâche n'a pas été rejoué. Un compte silencieux ne peut pas être distingué avec certitude d'une collecte incomplète ; de nouveaux scans demandent une vérification.
Prochaine étape
Actualiser les pièces puis confirmer l'exécution quotidienne et la réception d'une alerte sur le poste habituel.
Exemples de critères de recette
Ces critères décrivent le résultat attendu. Ils ne constituent pas, à eux seuls, des tests réussis.
- Introduire un trou de numérotation et une rupture de solde dans un jeu fictif : les deux anomalies doivent apparaître avec le compte et la période concernés.
- Exécuter deux alertes identiques le même jour : un seul envoi doit être enregistré ; un échec SMTP doit rester retentable.
Parlons de votre projet
Un besoin concret.
Une première discussion.
Un processus trop manuel, une donnée peu fiable ou une idée à tester ? Commençons par clarifier ce qui vous serait vraiment utile.
Échanger avec Loïc