Agent IA local : contrôler vos données chaque nuit
Découvrez comment MorningDrop associe Gemma en local et des contrats de données pour vérifier les exports nocturnes sans envoyer vos fichiers dans le cloud.
MorningDrop : un agent IA local pour vérifier vos données pendant la nuit
Chaque matin, des équipes ouvrent les mêmes dossiers, parcourent les mêmes fichiers et vérifient que les exports de la veille n'ont pas déraillé. Le plus souvent, tout va bien. Puis il suffit d'une colonne mal formatée, d'un code devise en minuscules ou d'un fichier inédit pour qu'une erreur reste invisible jusqu'à ce qu'un rapport, un tableau de bord ou un traitement en aval sorte un résultat incohérent.
MorningDrop automatise cette vérification avec une architecture volontairement simple : du code classique valide les données, un modèle Gemma exécuté localement résume les anomalies, puis un second contrôle vérifie la réponse du modèle. Le tout peut tourner sur une machine sans connexion Internet, par exemple via une tâche planifiée.
L'objectif n'est pas seulement d'utiliser un modèle « ouvert ». C'est surtout de limiter ce que le modèle fait réellement, et de vérifier ce qu'il renvoie. Voici comment fonctionne MorningDrop, ce qu'il peut apporter à une équipe qui reçoit des exports externes, et les compromis à considérer avant de l'adopter.
Le problème : vérifier des fichiers qui ne vous appartiennent pas
Les fichiers d'échange sont rarement pensés comme des interfaces robustes. Un fournisseur dépose un CSV dans un répertoire partagé, un outil de commerce exporte les commandes de la nuit, ou un service transmet des données clients en JSONL. Tout marche... jusqu'au jour où une règle change sans prévenir.
Ça peut être une devise qui passe de USD à usd, une quantité négative utilisée pour un remboursement, un code pays qui ne respecte plus le format, ou un nouveau fichier de livraisons que personne n'a encore documenté. Sur le moment, l'anomalie peut paraître bénigne. En aval, elle peut pourtant fausser un calcul, bloquer un import ou faire dériver les indicateurs.
Le contrôle manuel coûte cher, pour une raison très simple : il faut le répéter même quand ça va bien. Une personne ouvre les exports, examine quelques lignes et cherche ce qui « sort ». Une fois, ça passe. Tous les matins, sur plusieurs fichiers, ça devient fatiguant, et la tentation de contrôler par échantillonnage apparaît. Résultat : une anomalie au milieu (ou à la fin) d'un fichier de plusieurs centaines de lignes peut facilement passer sous le radar.
MorningDrop vise justement ce travail répétitif. L'outil surveille un dossier et s'occupe des vérifications initiales sur les nouveaux fichiers. Il ne s'adresse pas uniquement aux équipes de données : toute organisation qui reçoit des exports de tiers (service client, commerce en ligne, finance, opérations) peut tomber sur le même problème.
Le projet est présenté dans le cadre d'un défi consacré à l'IA open source. Son parti pris est pragmatique : l'IA ne tranche pas « est-ce conforme ». La décision repose sur des règles explicites, écrites dans des contrats de données. Le modèle intervient ensuite pour transformer les résultats de validation en un résumé lisible et proposer des pistes de correction.
Cette séparation évite de demander à un LLM ce qu'il fait mal quand une règle peut être codée et testée de façon déterministe.
Comment MorningDrop organise ses contrôles
MorningDrop suit une chaîne assez directe : repérer les fichiers récents, appliquer les contrats disponibles, résumer les anomalies si besoin, puis produire un rapport consultable le matin. L'outil peut être lancé depuis cron, un minuteur systemd ou launchd. Une commande de surveillance est aussi proposée pour interroger régulièrement le dossier.
Des règles explicites pour les fichiers connus
Chaque jeu de données peut être décrit par un contrat YAML : types attendus, champs obligatoires, motifs de validation, valeurs autorisées ou plages numériques. MorningDrop s'appuie sur DataContractGate, via le paquet Python contractgate, pour contrôler les lignes hors ligne.
Les cellules d'un CSV sont converties vers les types attendus avant validation. Si une valeur ne peut pas être convertie, elle n'est pas « maquillée » : elle reste une chaîne et peut être signalée comme une incompatibilité de type. C'est important. Une conversion trop permissive peut donner l'impression qu'un fichier est propre tout en laissant passer une donnée incorrecte.
Le système vérifie toutes les lignes couvertes par le contrat, pas seulement un échantillon. Dans l'exemple fourni, un fichier de commandes contient 240 lignes, dont 63 échouent, notamment sur les devises et les quantités. Le rapport liste les fichiers, les contrats, le nombre de lignes réussies ou en échec, ainsi que les champs concernés.
Un contrat proposé pour les nouveaux jeux de données
Un fichier inconnu, lui, pose un problème différent : il n'existe aucune règle approuvée pour dire s'il est valide. MorningDrop peut alors proposer une première version de contrat à partir des données (types, plages, petites listes de valeurs, motifs de dates), puis vérifier que ce contrat est cohérent.
Cette proposition est enregistrée dans contracts/_proposed/. Elle n'est pas appliquée automatiquement. Une personne doit l'examiner, la corriger si nécessaire, puis la déplacer vers le répertoire des contrats actifs.
C'est une limite utile. Une inférence décrit ce que le fichier contient aujourd'hui, mais ne prouve pas que la règle métier voulue est celle-là. Si les montants observés ne dépassent jamais 500 €, ça ne signifie pas que 500 € est une limite valide. Accélérer avec un brouillon aide, mais l'approbation reste une décision humaine.
Un résumé uniquement quand il apporte quelque chose
Si toutes les lignes passent, MorningDrop n'appelle pas le modèle. Il écrit un message court qui confirme que les fichiers ont été contrôlés et que tout est conforme. En cas d'anomalie, les résultats synthétiques sont envoyés à Gemma via Ollama.
Le modèle reçoit les noms de fichiers et de champs, le nombre d'anomalies, les messages de validation et les règles enfreintes. Il ne reçoit pas les lignes complètes, et les lignes conformes ne lui sont pas transmises. En sortie, Gemma produit un résumé en deux lignes et des suggestions de correction. Le résultat est enregistré dans un rapport Markdown, un fichier JSON et un latest.txt pratique à consulter.
Cette approche réduit le volume envoyé au modèle et évite de l'utiliser quand ce n'est pas nécessaire. Elle ne remplace pas une vérification de la configuration et des paramètres de journalisation, mais elle limite l'exposition par construction.
Pourquoi contrôler aussi la réponse de Gemma
Un modèle local n'est pas « automatiquement fiable » juste parce qu'il tourne hors ligne. Pendant le développement de MorningDrop, plusieurs réponses problématiques ont été observées : un petit modèle répétait les consignes au lieu de résumer, un autre inventait des échecs sur un fichier qui n'avait pas de contrat, et une proposition de plage numérique ne respectait pas la règle réelle.
Une réponse peut aussi être du JSON valide sans être vraie. Vérifier la structure ne suffit donc pas. MorningDrop applique deux niveaux de contrôle avant d'afficher le résumé.
Une structure de sortie contractuelle
La réponse de Gemma est validée par AISchemaGate à partir d'un contrat distinct. Celui-ci impose notamment un statut autorisé (vert, jaune ou rouge), une longueur minimale et maximale pour les deux lignes du résumé, et des champs obligatoires pour chaque correction proposée.
Le modèle reçoit aussi une contrainte de format JSON avec schéma via Ollama. Ça aide à obtenir une réponse exploitable dès le premier essai, mais ça ne garantit pas que les affirmations soient correctes. Le contrat vérifie la forme ; il faut encore vérifier l'ancrage dans les faits.
Des contrôles d'ancrage dans les résultats
MorningDrop compare aussi les affirmations du modèle aux résultats déterministes. Le statut doit correspondre au fichier ayant le niveau d'alerte le plus élevé. Le résumé doit mentionner le fichier prioritaire. Les nombres cités doivent déjà exister dans les faits disponibles, et chaque suggestion doit viser un fichier réel ainsi qu'un champ effectivement en échec.
Ce dernier point est particulièrement utile. Un modèle peut produire une phrase convaincante et y glisser un chiffre inventé. Vérifier que les chiffres proviennent des résultats évite ce risque sans obliger quelqu'un à relire chaque ligne du rapport.
Si la réponse ne passe pas, les erreurs sont renvoyées au modèle dans une demande de correction. Les suggestions invalides peuvent être écartées sans jeter le reste. Et si le modèle ne parvient pas à produire une réponse acceptable, ou si Ollama n'est pas disponible, un modèle de texte classique génère le rapport à partir des mêmes résultats de validation.
Ce mécanisme de repli compte, surtout pour une tâche planifiée. Un résumé plus « élégant » est agréable, mais la vérification ne doit pas dépendre d'un service de génération. Le rapport déterministe reste disponible même quand le modèle est lent, indisponible ou incapable de respecter son contrat.
Des performances à mesurer dans votre environnement
Le projet indique qu'avec Gemma 3 4B, une réponse peut être obtenue en environ 20 à 35 secondes sur une machine utilisant uniquement son processeur, selon la configuration et l'exécution. Les modèles plus petits (1B ou 270M testés) peuvent échouer aux contrôles et déclencher le modèle de secours.
Le point à retenir : ce comportement évite une fausse impression de fiabilité. Une tâche lancée la nuit peut tolérer quelques dizaines de secondes d'attente. En revanche, pour un traitement interactif ou sur de gros volumes, il faut mesurer le temps réel sur vos machines, ainsi que l'impact mémoire et le temps de démarrage.
Ce que le local change, et ce qu'il ne change pas
Exécuter un modèle localement répond à des contraintes concrètes. Les exports reçus peuvent contenir des données personnelles, des informations commerciales ou des éléments soumis à des engagements contractuels. Dans un contexte européen, décider de transférer ces données vers une API hébergée implique une analyse juridique, technique et organisationnelle. Le traitement local évite d'envoyer les fichiers à un fournisseur distant, mais ne rend pas un système conforme au RGPD à lui seul.
Il faut aussi maîtriser les accès au poste ou au serveur, les journaux, la durée de conservation des rapports, les sauvegardes et les droits des utilisateurs. Avoir les données chez soi aide, mais ce n'est pas une politique de sécurité.
Le fonctionnement hors ligne a un autre avantage. Une tâche lancée à 5 h 30 ne dépend pas d'une clé d'API expirée, d'une limite de débit ou d'une panne chez le prestataire. Le coût par appel disparaît aussi, même si l'infrastructure locale n'est pas gratuite : il faut compter le matériel, la consommation électrique, la maintenance et le temps d'exploitation.
MorningDrop utilise Gemma via Ollama, mais le projet indique qu'un serveur local compatible avec l'interface OpenAI peut aussi convenir, notamment avec llama.cpp, vLLM ou LM Studio. Cette flexibilité permet de choisir un modèle selon le matériel et de le remplacer sans réécrire toute la chaîne. En pratique, changer de modèle impose toutefois de refaire les tests : les formats de sortie et la qualité des suggestions peuvent varier.
Pour savoir si cette architecture vous convient, posez-vous quatre questions :
- Les fichiers sont-ils assez sensibles pour rendre un traitement distant difficile à accepter ?
- Les règles de validation peuvent-elles être formulées de façon déterministe ?
- Le délai d'exécution local est-il compatible avec votre fenêtre de traitement ?
- Une solution de secours sans modèle permet-elle de garder le contrôle en cas d'échec ?
Si les données sont peu sensibles, si le volume est faible et si une API hébergée est déjà acceptée, un service externe peut produire des formulations plus fluides avec moins de gestion. Si la confidentialité, l'autonomie ou la prévisibilité des coûts priment, le local mérite d'être évalué. Le bon choix dépend du coût total et des contraintes opérationnelles, pas d'une préférence abstraite pour l'open source.
Pour aller plus loin, consultez le dépôt de MorningDrop et l'article de présentation du projet. Ces ressources donnent des exemples, des rapports et des options d'exécution.
Conclusion : automatiser le contrôle, pas le jugement
MorningDrop montre une approche cohérente de l'IA locale : confier les règles vérifiables à du code, limiter le modèle à la synthèse, puis contrôler sa réponse avant de la présenter. L'agent automatise le travail répétitif sans transformer une génération plausible en validation.
Pour une équipe qui reçoit chaque nuit des exports non maîtrisés, le meilleur point de départ consiste à formaliser les règles d'un ou deux fichiers fréquents, puis à mesurer le temps gagné et les anomalies détectées. Ensuite seulement, décidez si l'exécution locale et le résumé par Gemma répondent à vos contraintes. Commencez par un contrôle déterministe qui marche ; ajoutez le modèle uniquement là où il améliore vraiment la lecture des résultats.