Pour faire tomber la barrière de la langue, il y a OpenAI.

ServiceNow présente les choses ainsi. En toile de fond, un accord sur 3 ans qui le verra, entre autres, exploiter GPT-5.2 pour développer des technologies de compréhension et de synthèse vocales. Au bout, nous promet-on, il y aura des agents multilingues qui fonctionneront sans passer par la modalité texte.

Les modèles GPT seront également mis à contribution sur la partie computer use (« agent utilisateur d’ordinateur »). En ligne de mire, notamment, l’orchestration des outils bureautiques et l’automatisation des systèmes hérités (ServiceNow évoque les mainframes).

Les modèles OpenAI, déjà bien ancrés dans ServiceNow

Dans la pratique, ServiceNow a déjà établi de multiples passerelles avec OpenAI.

Sur sa plate-forme, les fonctionnalités conversationnelles, génératives et agentiques sont majoritairement regroupées sous la marque Now Assist.

Les produits Now Assist s’installent comme des plug-in. Ils donnent accès à trois types de composantes : des skills génératives, des agents et des flux agentiques. Ces briques ciblent généralement un usage au sein d’une application. Par exemple, pour les skills, la génération de documentation sur la partie gestion du travail collaboratif. Pour les workflows agentiques, l’obtention de conseils de gouvernance dans la CMDB.

Certains flux agentiques opèrent au niveau de la plate-forme : enquêter sur des incidents, créer des tâches à partir d’images, proposer des réponses à un sondage…

Par défaut, Now Assist repose sur un service interne, qui associe des modèles maison spécialisés* et des modèles ouverts « sélectionnés, configurés ou améliorés par ServiceNow, sa communauté ou ses partenaires ».

Pour certaines skills, il est possible de basculer sur des fournisseurs alternatifs : Google (Gemini 2.5 Flash et 2.5 Pro), Anthropic (Claude 3.7 Sonnet sur Amazon Bedrock)… ou OpenAI (GPT-4.1 et GPT-4.1-mini sur Azure OpenAI).

Avec toute application est installé un « contrôleur d’IA générative ». Il permet d’interfacer des LLM externes par API, au niveau des concepteurs de flux, d’agents et de scripts. En standard, cela donne quatre possibilités :

• Générer du texte à propos d’un topic ServiceNow
• Résumer un topic
• Créer un use case et un prompt associé
• Faire de l’analyse de sentiment

Ce contrôleur fait la passerelle avec OpenAI et Azure OpenAI. Ainsi qu’avec Google, Aleph Alpha, Amazon (Bedrock) et IBM (watsonx). Il inclut aussi un connecteur générique.

* En tête de liste, un modèle 12B à usage général (création de flux, modération, écriture de code…) fondé sur Mistral Nemo Instruct.

Illustration générée par IA

The post ServiceNow et OpenAI embrayent sur le vocal… et le legacy appeared first on Silicon.fr.

Avec 132 magasins en France et 1 400 collaborateurs, Saint-Maclou fait face à des enjeux data complexes. Entre la gestion des ventes, du service de pose, de la logistique et des stocks, l’enseigne basée à Lezennes devait jongler avec de multiples sources de données dispersées. Un casse-tête qui freinait considérablement ses ambitions analytiques.

Un système legacy qui bride l’innovation

Le constat de départ était sans appel : le système décisionnel historique de Saint-Maclou reposait sur des flux développés et maintenus manuellement. Chaque nouveau projet d’analyse impliquait d’identifier précisément les bases sources, tables et colonnes pertinentes, puis de développer spécifiquement les flux d’alimentation nécessaires.

Cette approche générait une charge de développement et de maintenance considérable, particulièrement lors des évolutions. Les data engineers passaient l’essentiel de leur temps sur la collecte de données, au détriment des activités à réelle valeur ajoutée comme la transformation et l’analyse. Les coûts de licences s’accumulaient, les délais de projets s’allongeaient, et l’expérimentation sur des cas d’usage avancés ou d’intelligence artificielle devenait quasiment impossible.

« Charge de développement, charge de maintenance, charge d’astreinte, coût de licence pour l’outil… Notre façon de travailler générait auparavant d’importants coûts  », explique Salmane Khamlichi, Responsable data chez Saint-Maclou.

Le virage vers le cloud et l’ELT

Pour sortir de cette impasse, Saint-Maclou a opté pour une refonte progressive de sa plateforme data, en basculant vers une architecture moderne sur le cloud. L’entreprise a d’abord déployé Snowflake comme base de données centrale, puis s’est posé la question cruciale de l’alimentation de cette nouvelle infrastructure.

Exit l’approche ETL (Extract Transform Load) classique. L’enseigne a retenu Fivetran pour sa compatibilité native avec Snowflake, sa robustesse validée lors d’un POC, et sa capacité à gérer de grandes bases SQL Server tout en connectant des sources critiques.

Aujourd’hui, Fivetran synchronise automatiquement les données d’une quinzaine de sources vers Snowflake, qu’elles soient hébergées on-premise ou dans le cloud : l’ERP Microsoft AX, les outils logistiques, les systèmes de vente et de gestion des stocks, ainsi que plusieurs sources marketing, dont le futur CRM Salesforce.

Avec cette approche ELT (Extract Load Transform), la phase de collecte ne constitue plus un goulot d’étranglement. Les données sont chargées brutes dans Snowflake, puis transformées selon les besoins métiers.

Des gains mesurables sur tous les plans

Les résultats sont spectaculaires. La collecte de nouvelles sources, qui prenait auparavant plusieurs jours voire plusieurs semaines, s’effectue désormais en quelques heures. Les projets restent dans un même sprint, évitant les allers-retours coûteux qui ralentissaient leur réalisation.

Côté ressources humaines, l’impact est tout aussi significatif. L’ingestion de données ne nécessite plus d’équivalent temps plein. Les data engineers se consacrent enfin aux opérations à forte valeur ajoutée : la transformation via DBT Core et l’exploitation intelligente des données. Les problématiques de maintenance sont devenues minimes.

La robustesse de la solution apporte également une tranquillité d’esprit appréciable. Les synchronisations sont stables et fiables, les évolutions des schémas sources n’entraînent pas d’interruption de service, et les équipes disposent de données actualisées et exploitables en toute confiance.

Autre bénéfice majeur : la centralisation. Là où les données étaient auparavant éparpillées dans de multiples applications métiers, elles sont désormais regroupées à 100% dans Snowflake. Cette vision unifiée permet d’envisager sereinement les futurs projets analytiques avancés et d’intelligence artificielle. L’équipe data travaille plus étroitement avec les équipes métiers (marketing, ventes, logistique) et gagne en réactivité.

Enfin, la plateforme Fivetran offre une maîtrise fine de la consommation et un monitoring précis des coûts liés aux projets data. « Cela nous permet notamment de travailler sur des sujets de prévision des ventes, d’intégrer rapidement de nouvelles sources pour enrichir les modèles et d’expérimenter à moindre coût de nouveaux cas d’usage data science », résume Salmane Khamlichi.

Photo : © DR

The post Comment Saint-Maclou accélère sa transformation data appeared first on Silicon.fr.

Terraform est efficace pour gérer de l’infrastructure ; pas des workflows data.

À force de s’en servir en conjonction avec Snowflake, Accor en est arrivé à ce constat. Entre absence de validation locale, gestion manuelle des dépendances et nécessité d’outils externes pour contrôler la qualité des données, la mise à l’échelle et la collaboration s’en trouvaient limitées.

Le groupe hôtelier a fini par basculer vers une stack associant dbt Core pour les transformations et un Airflow managé (Astro) pour l’orchestration, avec la bibliothèque Cosmos – proposée par le fournisseur d’Astro – pour faire la passerelle. Cette dernière déduit automatiquement le lignage des tâches et déclenche les contrôles de data quality immédiatement après la matérialisation d’une table ou d’une vue lors d’un dbt run.

Une déploiement Airflow « léger » qui rafraîchit uniquement les DAG

Le passage au tandem dbt-Airflow a impliqué un changement des pratiques de data engineering. Entre autres, passer d’étapes séparées pour la création et le peuplement de tables à une action unique utilisant exclusivement la commande SQL SELECT.

Chaque équipe possède son repo et déploie indépendamment. Tout part d’un template géré avec Copier. L’ensemble est réconcilié dans le projet principal, poussé vers Astro. Les scripts CI/CD sont centralisés dans un dépôt étiqueté.

Par défaut, Astro reconstruit l’image Docker à chaque modification. Le déploiement : dure alors environ 5 minutes. Il existe toutefois un mode « léger » dont Accor a tiré parti. Celui-ci synchronise simplement les DAG (graphes acycliques dirigés, représentant les tâches à exécuter) et évite ainsi un rebuild.

Pour exploiter ce mécanisme, le pipeline CI/CD place chaque projet dbt dans le répertoire dags/ du projet principal. Le déploiement dure alors environ 1 minute. Il couvre 95 % des exécutions. L’autre option reste utilisée pour l’upgrade des dépendances et les changements sur l’image de base (i.e. modification des fichiers include, requirements.txt ou Dockerfile).

Imbriquer chaque projet dbt dans le répertoire dags/ permet à Cosmo de générer automatiquement les tâches Airflow correspondantes. Et de construire des DAG sans intervention manuelle. Les tests peuvent se faire en local, avec dbt run et dbt test.

Accor vise un pipeline pour chaque équipe

Avec une telle configuration multilocataire, les cycles d’upgrade d’Airflow peuvent ralentir. Il n’y a, par ailleurs, pas moyen de prioriser des jobs. Et l’existence d’un seul chemin CI/CD vers la prod pose la question du point unique de défaillance, en plus des risques de conflit de noms et de bibliothèques.

Accor réfléchit donc à donner à chaque équipe son pipeline et à découpler la propriété du code. Tout en permettant l’hibernation des workflows à faible trafic.

Illustration générée par IA

The post Accor a écarté Terraform de sa stack data engineering appeared first on Silicon.fr.