Data & AI, construire l’IA, du socle de données aux cas d’usage

Nous concevons des plateformes de données adaptées aux contraintes et aux usages, pouvant notamment s’appuyer sur des architectures lakehouse et des organisations en couches de type medallion (bronze, silver, gold). Chaque couche répond à des règles explicites de qualité, de transformation et d’exposition des données.

Les transformations sont versionnées, testées et documentées comme du code. Selon l’architecture retenue, nous mettons en œuvre des approches ETL ou ELT et nous pouvons nous appuyer sur des outils déclaratifs tels que dbt afin d’améliorer la reproductibilité, les tests, la documentation et la traçabilité des transformations.

Le choix entre traitements batch et streaming est déterminé par les besoins du cas d’usage : latence, volumétrie, fréquence, contraintes de rejeu et caractéristiques des systèmes sources et cibles. Selon ces contraintes, nous nous appuyons notamment sur des technologies de streaming et d’event processing telles que Kafka et Flink, ou sur des moteurs de traitement distribués comme Spark pour les traitements batch et les rejeux.

Les pipelines sont conçus pour favoriser l’idempotence et permettre des rejeux maîtrisés et déterministes, afin de limiter les risques de duplication ou d’incohérence de l’état aval. La gestion de l’évolution des schémas et, lorsque nécessaire, l’utilisation d’un registre de schémas permettent de maîtriser les changements de structure et de réduire le risque de dérives silencieuses.

La qualité des données est intégrée aux chaînes de traitement selon une approche Data Quality as Code, à travers des contrôles déclaratifs pouvant s’appuyer sur des solutions telles que Great Expectations, Soda ou Deequ. Selon leur criticité, ces contrôles peuvent générer des alertes ou bloquer la promotion des données.

Nous définissons également des indicateurs et SLO adaptés aux données - fraîcheur, complétude, unicité, cohérence ou distribution - afin de mesurer leur qualité en exploitation.

Enfin, les mécanismes de catalogue et de lignée, à travers des solutions telles que DataHub, OpenLineage ou Collibra, facilitent l’analyse d’impact avant changement, la traçabilité des données sensibles et l’audit des politiques de contrôle d’accès.

La BI et la dataviz restent hors périmètre de cette offre : nous construisons et industrialisons le socle Data nécessaire à leur exploitation, sans couvrir la conception des tableaux de bord métier.

Nous structurons le cycle autour d'un registre de modèles (MLflow) qui fait foi : chaque version est liée à son jeu de données (versionné via DVC), à son code, à ses hyperparamètres et à ses métriques d'évaluation. Sans cette traçabilité, le « ça marchait la semaine dernière » est ingérable. La reproductibilité n'est pas un confort : c'est la condition de l'auditabilité et du rollback.

Le piège central est le training-serving skew : une transformation calculée différemment à l'entraînement et à l'inférence. Nous le neutralisons avec un feature store (Feast, Tecton) qui assure la parité online/offline et matérialise les features avec une fraîcheur maîtrisée. Le déploiement suit des stratégies progressives, shadow pour comparer sans risque, puis canary avec critères de promotion automatiques, et un chemin de rollback testé. Pour le serving, nous arbitrons entre batch et online selon la latence cible : ONNX / TorchServe / Triton pour l'inférence temps réel, avec autoscaling (y compris GPU) piloté par la charge réelle.

En production, les données et les conditions d'utilisation peuvent évoluer et dégrader les performances d'un modèle. Nous instrumentons le drift (data drift, concept drift) et la dégradation de performance (Evidently, Arize, WhyLabs), avec des déclencheurs de réentraînement reliés à des seuils, et non à un calendrier arbitraire. La CI/CD couvre les modèles et les prompts : tests de non-régression sur golden sets, validation avant promotion, approbations tracées. La gouvernance (model cards, lignée, Responsible AI Dashboard) documente les limites, les biais connus et le périmètre d'usage.

Une architecture RAG sérieuse commence par l'ingestion : segmentation (chunking) adaptée à la structure documentaire, pas un découpage naïf à taille fixe qui casse le sens, enrichie de métadonnées exploitables au filtrage. La récupération est hybride par défaut : recherche dense (embeddings) combinée à du lexical (BM25), puis reranking pour remonter les passages réellement pertinents. Nous mesurons la qualité de récupération (recall@k, MRR) avant même de parler de génération, parce qu'un RAG qui récupère mal hallucine, quel que soit le modèle.

Côté génération, nous imposons l'ancrage (grounding) et la citation des sources, avec des seuils de confiance et un comportement explicite de refus quand le contexte est insuffisant. Le choix RAG vs fine-tuning se tranche sur des critères concrets, fraîcheur de la connaissance, traçabilité exigée, coût, sensibilité des données, et n'est pas exclusif : on combine souvent récupération et adaptation légère (PEFT / LoRA).

L'évaluation est le cœur du dispositif, pas une étape finale. Nous construisons des golden sets et un harnais d'éval mesurant faithfulness (fidélité aux sources), pertinence de la réponse et complétude, avec du LLM-as-judge calibré contre du jugement humain. Les prompts sont versionnés et testés en non-régression au même titre que du code. Les garde-fous (détection PII, filtrage des sorties, protection contre l'injection de prompt directe et indirecte) sont conçus avec l'offre Sécurité de l'IA, une chaîne RAG est une surface d'attaque.

Nous traitons les trois piliers, logs, métriques, traces, autour de conventions sémantiques cohérentes, avec OpenTelemetry comme standard d'instrumentation afin de favoriser l'interopérabilité et de limiter la dépendance à un fournisseur. La traçabilité distribuée (Jaeger, Tempo) relie une requête d'un service à l'autre, condition pour diagnostiquer une latence anormale ou une erreur intermittente. Le contrôle de la cardinalité des métriques est une discipline de fond : une étiquette mal choisie peut fortement augmenter les coûts et dégrader les performances du backend.

À cela s'ajoute l'observabilité de la donnée et des modèles, spécifique aux systèmes data/IA : moniteurs de fraîcheur, de volume, de distribution et d'anomalies (Monte Carlo), et suivi du drift pour les modèles. Un pipeline qui tourne « au vert » mais produit des données obsolètes ou faussées est un incident silencieux que seule cette couche détecte.

La chaîne de collecte est dimensionnée pour le débit réel : agents légers (Filebeat, Vector, Fluentd) en bordure, normalisation (ECS), puis stockage indexé (Elastic / OpenSearch) ou colonne pour l'analytique de logs (ClickHouse) selon le profil de requête. L'alerting est conçu pour le rapport signal/bruit : alertes reliées à des SLO et des budgets d'erreur, déduplication et regroupement (Alertmanager), suppression du bruit qui détruit la confiance des équipes d'astreinte. Pour les plateformes Elastic, une capacité dédiée couvre l'architecture, la collecte, la sécurité, les coûts et l'IA appliquée aux opérations.

Uneety est Top France Partner Elastic : licences, intégration et exploitation passent par un point d'entrée unique, avec un centre de services et une expertise senior. Une plateforme Elastic utile répond à des besoins opérationnels précis tout en restant exploitable, résiliente et dimensionnée pour les usages réels. Les applications distribuées, le cloud et Kubernetes multiplient les sources de données : dispersées ou mal structurées, elles empêchent de relier une alerte à son contexte, de retrouver l'origine d'un ralentissement ou de distinguer un événement isolé d'un incident récurrent. Nous traitons la chaîne dans son ensemble : produire les bons signaux, fiabiliser leur acheminement, organiser leur stockage et permettre aux équipes de les exploiter.

L'architecture se définit à partir des usages : sources à collecter, volumes quotidiens, pics d'ingestion, rétention, profils de requêtes et objectifs de continuité. Sur les environnements autogérés comme sur Kubernetes avec ECK, nous examinons les rôles des nœuds, la répartition des données, les domaines de panne et le stockage. La présence de plusieurs zones ne suffit pas à qualifier la résilience : les scénarios de perte d'une zone et de reprise sont étudiés, et les restaurations sont testées, car une sauvegarde qui existe ne prouve pas que le service peut être rétabli. Les migrations et montées de version sont préparées par une revue des dépendances, des dépréciations et des mécanismes d'authentification.

Une donnée collectée doit rester exploitable au moment de l'incident. Nous structurons les flux depuis les sources jusqu'à l'indexation : horodatage, parsing, enrichissement, typage et conventions de nommage, avec ECS lorsque cela convient. Le choix entre Elastic Agent, Logstash, collecteurs OpenTelemetry et transport intermédiaire dépend du débit, des transformations et des contraintes d'exploitation. Le comportement en cas d'indisponibilité d'une destination est prévu dès la conception : buffering, files persistantes, absence d'erreurs silencieuses.

Côté observabilité, nous partons des parcours et des applications prioritaires pour relier logs, métriques et traces. Nous accompagnons l'instrumentation APM et OpenTelemetry (EDOT) en distinguant la configuration applicative de la collecte sur l'infrastructure, et nous vérifions la propagation du contexte et la couverture réelle des services. Les tableaux de bord et les alertes servent des décisions concrètes : identifier les services dégradés, qualifier l'impact, orienter l'investigation.

La sécurité couvre deux dimensions. Sécuriser la plateforme : communications chiffrées, certificats, identités techniques et droits attribués selon le principe du moindre privilège. Exploiter les événements de sécurité avec Elastic Security : intégration des sources, activation, adaptation et investigation des règles. Une règle présente dans l'outil ne constitue pas à elle seule une couverture validée : il faut vérifier les événements disponibles et son comportement dans le contexte du client.

Les coûts dépendent autant de l'organisation des données que des ressources allouées. Nous analysons les volumes ingérés, les index, la taille et le nombre des shards, la rétention et les usages de recherche, puis nous réévaluons les politiques de cycle de vie et la répartition entre niveaux de stockage. Sur Elastic Cloud et Serverless, nous mettons en place le suivi de consommation et des alertes budgétaires. Chaque optimisation est un arbitrage documenté entre fraîcheur, durée de conservation, délai d'accès et coût, vérifié par une mesure après changement.

L'historique d'incidents et les données d'observabilité peuvent enfin servir de base à une investigation assistée par l'IA : rechercher des événements similaires, reconstituer une chronologie, proposer des hypothèses de causes à examiner. Nous construisons des preuves de concept ciblées, évaluées sur des cas connus, avec des accès cadrés et une validation humaine. Une corrélation ou une réponse du modèle n'est pas une preuve de causalité.

Nous intervenons en audit et cadrage, en accompagnement projet (déploiement, migration, chaîne de collecte, chantier d'observabilité), en expertise ponctuelle avec transfert de compétences, ainsi qu'en régie et en infogérance de plateformes Elastic. Les objectifs et les indicateurs sont définis avec vos équipes : nous ne promettons pas de gains chiffrés avant mesure.