Dans les opérations modernes, qu’il s’agisse d’agriculture, d’industrie, de logistique ou de santé, chaque minute compte. L’exemple qui suit provient de la gestion d’élevages, mais le défi sous-jacent est universel : des communications non structurées et volumineuses cachent des signaux opérationnels précieux, souvent ignorés.
Chaque jour, agriculteurs et employés échangent des milliers de messages non structurés à propos de l’alimentation, de la mortalité, des contrôles de biosécurité ou d’incidents imprévus. Au milieu de ce flux constant de conversations se nichent des signaux critiques : un avertissement que quelque chose pourrait mal tourner.
Traditionnellement, ces messages étaient impossibles à suivre de manière systématique. Résultat : des retards dans les réponses, des anomalies manquées et des inefficacités dans la gestion des exploitations. Japfa a donc entrepris de transformer la manière dont les données de biosécurité sont exploitées, en intégrant directement l’intelligence artificielle dans le flux de communication. Nous avons accompagné cette initiative en industrialisant et en faisant passer à l’échelle la preuve de concept existante sur Snowflake, afin d’assurer un fonctionnement fiable à l’échelle de l’entreprise.
En tant qu’architecte de la solution, j’ai dirigé la conception et la mise en œuvre de l’architecture de production avec un objectif simple : préserver la fluidité de l’expérience utilisateur, garantir la fiabilité des données et laisser Snowflake gérer la complexité. Ce qui suit décrit comment ce flux transforme les messages bruts en informations exploitables en temps réel. Les sections suivantes détaillent l’architecture du workflow, les décisions clés que nous avons prises, les raisons de ces choix, et les compromis que nous avons acceptés pour maintenir un système rapide, gouvernable et nativement intégré à Snowflake.
Toute analyse commence par un message. Sur les fermes, ces messages transitent via Zalo : un rapport, une note texte (parfois accompagnée d’une photo) ou d’autres pièces jointes. Une application d’ingestion sur mesure agit comme intermédiaire, extrayant les messages directement vers Snowflake pour qu’ils soient prêts à être traités en quelques secondes.
Mais les pièces jointes sont un cas particulier. Les photos, par exemple, ne peuvent pas être intégrées directement dans Snowflake comme du texte. L’application les transfère donc dans un bucket Amazon S3, en leur attribuant des noms et métadonnées homogènes. Cela les rend durables, traçables et immédiatement disponibles pour les traitements en aval.
Le choix de Zalo ne relevait pas d’une question technologique, mais d’un principe d’adaptation : aller là où les équipes travaillent déjà. Et ce schéma reste flexible : demain, ce même pipeline pourrait être alimenté par WhatsApp, Telegram ou Slack. L’important n’est pas l’application utilisée, mais que chaque message et chaque image soient stockés dans un format exploitable par Snowflake pour déclencher l’étape suivante du flux.
Une fois les données collectées, la question devient : comment les traiter de manière efficace et fiable ? En collaboration avec les équipes de Japfa, nous avons conçu une architecture fondée sur trois principes directeurs : simplicité, traçabilité et modularité. Ces principes s’appliquent à tout flux événementiel à haut volume, qu’il provienne d’agriculteurs, de machines industrielles, de capteurs IoT ou de systèmes de support client.
Chaque étape du traitement suit le même modèle : une tâche associée à un notebook, déclenchée uniquement lorsqu’un stream détecte de nouvelles données.
Cette conception maintient un flux propre et cohérent. Chaque tâche sait exactement quel notebook exécuter, chaque notebook remplit une fonction bien délimitée, et chaque stream garantit que la logique ne s’active que lorsqu’il y a effectivement de nouvelles données à traiter. Cette modularité rend le système traçable de bout en bout et simple à étendre lorsque de nouveaux cas d’usage apparaissent.
Snowflake rend tout cela possible sans les lourdeurs de maintenance habituelles. En exploitant les streams – le mécanisme de capture de changements (Change Data Capture, ou CDC) intégré à Snowflake – nous pouvons traiter uniquement les deltas, c’est-à-dire les données nouvelles, sans retraiter l’ensemble du jeu de données. Cela maintient l’utilisation des ressources strictement alignée avec le volume et la vitesse des données, garantissant ainsi une mise à l’échelle sans coûts inutiles.
Concrètement, cela signifie que chaque étape de l’application – de l’ingestion à la classification, jusqu’à l’évaluation des alertes – ne s’exécute que sur des données fraîches. Résultat : un pipeline efficace, prévisible et transparent, tout en restant suffisamment flexible pour évoluer avec les besoins croissants de Japfa.
Une fois les données entrantes reçues, la première étape majeure est la classification. Avant que toute logique d’alerte ou d’évaluation puisse s’exécuter, le système doit comprendre la nature du contenu qu’il traite : s’agit-il de texte brut, d’une pièce jointe image, ou d’une combinaison des deux ? Et surtout, à quelle catégorie métier appartient-il : biosécurité, santé animale, ou performance des troupeaux.
Cette phase ne consiste pas seulement à attribuer des étiquettes. Elle inclut aussi plusieurs étapes clés de prétraitement et d’ingénierie des données :
Faire correspondre les messages à leurs pièces jointes stockées dans S3.
Relier les conversations aux données de référence des groupes d’utilisateurs.
Gérer les doublons issus de la couche d’ingestion.
Standardiser les entrées pour garantir une cohérence dans les traitements en aval.
Pour la classification proprement dite, nous avons exploité AISQL directement dans Snowflake. Les premiers tests ont comparé les fonctions AI_COMPLETE et AI_CLASSIFY ; nous avons constaté que AI_CLASSIFY produisait des résultats équivalents tout en consommant beaucoup moins de jetons. Cette efficacité s’est révélée cruciale, non seulement pour le contrôle des coûts, mais aussi pour permettre la mise à l’échelle du système afin de traiter des milliers de messages quotidiens sans goulots d’étranglement.
À partir de ce stade, le système peut router chaque message de manière déterministe vers le flux de traitement approprié, garantissant que les alertes et actions de suivi soient toujours associées au bon contexte opérationnel.
Une fois qu’un message est classé dans son cas d’usage, il emprunte un flux de traitement dédié. Chaque flux dispose de sa propre logique et de son propre modèle, adaptés à la nature des données et aux besoins opérationnels.
Pour la plupart des entrées textuelles, nous utilisons AI_COMPLETE avec les modèles Llama-Maverick, qui offrent le meilleur compromis entre précision et coût.
Les images, en revanche, introduisent de nouvelles exigences. Pour en extraire des informations structurées, plusieurs options ont été évaluées :
AISQL – modèles de classification à base de prompts (Claude, Pixtral, Llama, GPT) ;
OCR via bibliothèques Python – telles que EasyOCR, Tesseract et PaddleOCR ;
Document AI – une fonctionnalité native de Snowflake, basée sur Arctic-TILT, permettant d’entraîner des modèles personnalisés.
Lors de notre démonstration, le scénario de mortalité porcine s’est révélé le plus exigeant – mais la même approche pourrait être utilisée dans de nombreux contextes visuels : suivi de l’état des équipements dans l’industrie, analyse de linéaires en grande distribution, ou contrôle qualité en logistique.
Le principe reste identique : classifier, extraire, et transformer du contenu non structuré en signaux exploitables, quel que soit le secteur.
Les éleveurs partagent souvent des photos d’animaux morts comme preuve de mortalité. Transformer ces images en données structurées demandait plus qu’une simple classification. Trois approches ont été testées :
AISQL, grâce à sa configuration pilotée par prompt, a donné des résultats fiables et s’est intégré facilement.
Les bibliothèques OCR classiques, même encapsulées dans des conteneurs et associées à des étapes de prétraitement, ont montré leurs limites face à la variabilité des conditions sur le terrain (lumière, angle, résolution), produisant des résultats incohérents.
Document AI s’est révélé le plus prometteur, avec la possibilité d’affiner les modèles et de les adapter au contexte spécifique. Cependant, sa disponibilité régionale limitée a empêché son adoption en production.
Finalement, nous avons retenu AI_COMPLETE avec les modèles GPT-4.x d’OpenAI, qui offraient le meilleur équilibre entre précision, adaptabilité et faisabilité opérationnelle.
Nous avons également évalué AI_EXTRACT comme alternative, mais ses performances restaient inférieures à celles de Document AI.
En production, le choix le plus fiable s’est donc avéré être AI_COMPLETE avec GPT-4.x, capable de fournir des résultats constants malgré la variabilité de la qualité des images ou des langues d’entrée.
Cette approche modulaire et orientée cas d’usage garantit que chaque type de donnée – texte ou image – est traité par le modèle et la logique les plus adaptés à ses caractéristiques, tandis que Snowflake assure une orchestration homogène et gouvernée à l’échelle du système.
Une fois les données transformées en informations semi-structurées, le système passe à l’étape d’évaluation.
À ce stade, différentes vérifications sont effectuées selon le cas d’usage concerné.
Dans certains cas, les résultats sont comparés à des valeurs de référence — par exemple, les preuves de mortalité sont confrontées aux indicateurs de performance du troupeau afin de détecter des taux de perte anormaux.
Dans d’autres, le processus recherche des anomalies ou évalue la conformité, comme la validation de photos de visiteurs par rapport à des listes d’accès autorisées.
Cette étape détermine si une alerte doit être déclenchée et si une réponse est nécessaire.
Lorsqu’une réponse est requise, un modèle de Génération d’IA (GenAI) rédige automatiquement le message, qui est ensuite renvoyé sur Zalo en réponse directe au message initial.
Ainsi, la logique d’évaluation transforme les données structurées en informations actionnables, bouclant la boucle avec un retour pertinent et immédiat, délivré dans le même canal où le signal est apparu.
Cette architecture peut sembler simple, mais ses implications sont majeures — et elles vont bien au-delà du secteur agricole.
Le même cadre peut transformer des communications, journaux d’événements, documents ou flux de capteurs en informations structurées et exploitables, dans n’importe quel domaine.
Dans le cas de Japfa, cela signifie une intelligence en temps réel des élevages.
Dans d’autres contextes, cela peut devenir un système d’alertes de maintenance prédictive, une solution de suivi patient, ou un contrôle qualité automatisé.
Le design trouve un équilibre essentiel :
il est ouvert et extensible, capable de se connecter à n’importe quelle plateforme de messagerie ou modèle d’IA,
tout en restant nativement intégré à Snowflake, garantissant gouvernance, maîtrise des coûts et sécurité.
Efficacité opérationnelle – les équipes reçoivent des alertes et du contexte en temps réel, réduisant le délai d’action dans les situations critiques.
Scalabilité – le système gère déjà texte et images, et sa conception modulaire permettra d’intégrer la vidéo et d’autres modalités futures sans refondre l’architecture.
Gouvernance et sécurité – en centralisant tout dans Snowflake, Japfa conserve un contrôle total sur l’accès aux données, leur traçabilité et la conformité.
Simplicité et observabilité – chaque étape est transparente, journalisée et modulaire. De l’ingestion à la génération d’alertes, l’observabilité est intégrée par conception, rendant le système à la fois efficace, explicable et digne de confiance.
En somme, cette architecture démontre que l’IA dans les opérations n’a pas besoin d’être complexe.
Avec Snowflake comme socle, elle peut être simple, traçable et ouverte par design, prête à évoluer avec de nouveaux cas d’usage tout en délivrant de la valeur dès aujourd’hui.
En tant qu’architecte de cette mise en œuvre avec Japfa, j’ai pu constater la puissance de la combinaison entre les capacités d’IA de Snowflake et l’approche pragmatique et orientée business de SBI.
Notre reconnaissance en tant que Snowflake Partner of the Year illustre parfaitement cette philosophie :
l’IA n’est pas une expérimentation, c’est une création de valeur concrète.
Ce qui me passionne le plus dans cette initiative, c’est qu’elle montre à quoi ressemblera l’avenir de l’IA opérationnelle : intégrée, invisible, et centrée sur le métier.
Les agriculteurs n’ont pas besoin de connaître Snowpipe, AISQL ou les LLM multimodaux.
Ce qu’ils perçoivent, c’est une réactivité accrue, moins de pertes, et la certitude que les problèmes sont détectés avant de devenir critiques.
Et ce n’est qu’un début.
Cette même base pourra demain soutenir l’analyse vidéo des conditions d’élevage, la surveillance prédictive de la santé animale, ou la prise de décision assistée par IA à grande échelle — et s’étendre tout aussi facilement à des secteurs complètement différents.
Une fois l’architecture en place, le cas d’usage devient simplement une variable.