Lorsque RAJA Group nous sollicite en 2024, la question n’est pas : « Quelle technologie choisir ? ». La vraie question est bien plus stratégique :

Quelle trajectoire data devons-nous construire pour le groupe, et Microsoft Fabric est-il le bon socle pour l’incarner ?

Avec ses 26 filiales européennes, son historique IT riche, des usages data variés et une organisation fortement distribuée, RAJA Group ne cherche pas une technologie. RAJA Group cherche une plateforme unique et un modèle opérationnel pérenne, capable d’accompagner son ambition data.

C’est sur cette base que commence notre collaboration.

Le cadrage : comprendre RAJA Group pour savoir si Fabric « fit » réellement (et inversement)

Notre mission initiale n’était pas d’analyser des volumes ou d’inventorier des sources. Il s’agissait d’abord de comprendre :

• la stratégie data du groupe ;
• les ambitions de transformation pour les années à venir ;
• la culture de développement et les pratiques existantes ;
• la maturité data et les contraintes opérationnelles ;
• le modèle organisationnel et sa capacité à s’approprier Fabric.

Chez Cellenza, nous sommes convaincus que :

une technologie se choisit parce qu’elle s’aligne avec la gouvernance, les usages et la culture de l’entreprise.

Nous avons donc construit avec RAJA Group une trajectoire data claire, durable, alignée sur les ambitions du groupe, basée sur une architecture de la plateforme et accompagnée d’un premier backlog pour structurer l’évolution. Ce travail a permis de valider que Fabric correspondait à la manière dont RAJA Group travaille, collabore et souhaite faire évoluer la donnée.

Co‑construire plutôt que livrer : la signature Cellenza

Dès le démarrage de la mise en œuvre, un principe s’impose :

Cellenza ne vient pas livrer une plateforme, mais aider RAJA Group à la construire et à se l’approprier.

Nous intégrons leurs équipes et travaillons main dans la main, en suivant les principes du Platform Engineering, qui constituent notre marque de fabrique :

• privilégier les outils plutôt que les solutions ponctuelles ;
• standardiser pour accélérer et fiabiliser ;
• industrialiser pour réduire les coûts de possession ;
• rendre les équipes clientes autonomes, pas dépendantes ;
• avancer de façon pragmatique, itérative et collaborative.

Ce mode de travail crée une dynamique d’apprentissage rapide et un engagement fort autour de la plateforme.

26 ERP intégrés en trois mois : quand l’industrialisation rencontre la capacité d’apprentissage

Le chiffre surprend souvent : 26 ERP intégrés en trois mois.

Pourtant, cette performance s’explique par deux facteurs clés :

L’industrialisation via un moteur d’intégration

Nous avons conçu avec RAJA Group un engine d’intégration permettant :

• de standardiser les patterns d’ingestion ;
• d’automatiser la répétition sur les 26 systèmes ;
• de sécuriser les flux sans reconstruire chaque pipeline ;
• d’offrir une base solide pour les évolutions futures.

Cet outil – aujourd’hui en version 2 – est au cœur de l’efficacité de la plateforme.

Une courbe d’apprentissage exceptionnelle

L’autre clé du succès : la montée en compétence des équipes RAJA Group.

Issues d’un univers SQL traditionnel, elles ont adopté Fabric en un temps record :

• pipelines et Lakehouses,
• notebooks et Spark,
• logique d’industrialisation,
• bonnes pratiques de gouvernance.

C’est l’une des révélations du projet :

bien accompagné et bien outillé, Fabric offre une courbe d’apprentissage sans équivalent.

Composer avec les limites de Fabric… et sa roadmap

En 2024, Fabric est encore en pleine évolution. Certaines fonctionnalités manquent encore ; d’autres arrivent trop tard pour les besoins immédiats.

Nous devons alors arbitrer entre :

• attendre une future fonctionnalité prévue dans la roadmap ;
• ou développer un outil interne pour répondre immédiatement au besoin.

Nous avons notamment construit du monitoring avancé et divers outils d’observabilité pour compléter les limites de l’époque.

Notre relation étroite avec Microsoft et la présence de MVP Fabric dans nos équipes ont été déterminantes pour faire les bons choix, anticiper les évolutions et garantir un socle stable malgré la jeunesse du produit.

2025 : quand la plateforme devient un écosystème

L’année 2025 marque une étape clé : la plateforme n’est plus un simple socle technique, mais un écosystème en croissance permanente, façonné à la fois par les besoins métiers et par l’expertise continue apportée par Cellenza.

Dès le début, nous avons structuré l’accompagnement autour d’un principe simple : faire évoluer la plateforme au même rythme que l’organisation, sans jamais perdre de vue les objectifs de long terme. Cette approche a permis d’inscrire Fabric dans une logique vivante, adaptable et durable.

Une amélioration continue structurée et portée par les usages

Chaque nouveau cas d’usage ouvre une opportunité d’améliorer la plateforme : optimiser un pattern d’ingestion, renforcer une couche de gouvernance, enrichir un modèle, ajuster l’architecture. Ces évolutions ne sont pas anecdotiques : elles permettent au socle Fabric de gagner en maturité, en robustesse et en cohérence.

Cellenza accompagne RAJA Group dans cette dynamique en apportant une vision experte sur ce qu’il faut améliorer, quand le faire et comment le faire. Ce rôle de « gardien du cadre » garantit que la plateforme continue d’évoluer de manière maîtrisée.

Une expertise Cellenza qui éclaire les choix technologiques

Tout au long de 2025, nous assurons :

• des revues régulières des développements ;
• des arbitrages technologiques pour orienter les évolutions ;
• une veille continue sur l’évolution de Fabric pour anticiper les impacts ;
• des recommandations d’architecture pour maintenir une cohérence globale.

Cette présence experte permet à RAJA Group de rester à jour tout en consolidant un socle stable et aligné avec sa stratégie data.

Une gestion maîtrisée des coûts et des capacités

La montée en charge implique un suivi attentif des consommations. Ensemble, nous mettons en place :

• une optimisation ciblée au bon moment (notebooks, Spark, stockage, organisation du Lakehouse) ;
• un capacity planning pour anticiper les besoins futurs ;
• des pratiques garantissant un équilibre sain entre performance, coûts et simplicité.

L’objectif : protéger les coûts tout en accompagnant la croissance de la plateforme.

RAJA Group ne « consomme » plus Fabric : RAJA Group le maîtrise, l’enrichit et l’utilise pour accélérer sa transformation. La plateforme est devenue un espace où les usages évoluent en continu, guidés par l’innovation et soutenus par l’expertise Cellenza.

L’IA et les Data Agents : une nouvelle ère d’innovation pour RAJA Group

Avec une plateforme désormais solide et pleinement maîtrisée, RAJA Group aborde en 2025 un territoire résolument tourné vers l’avenir : celui de l’IA intégrée à Fabric, et en particulier des Data Agents. Et l’enthousiasme est à la hauteur du potentiel.

Les Data Agents représentent une avancée majeure : des agents intelligents, directement connectés aux données, capables de comprendre une question métier, d’aller chercher les données pertinentes, de déclencher des traitements automatisés et de restituer une réponse contextualisée. Une rupture dans la manière d’interagir avec la donnée.

RAJA Group a choisi non seulement d’expérimenter cette fonctionnalité, mais de l’explorer en profondeur — à la fois sous l’angle technique (est-ce que ça fonctionne réellement dans notre contexte ? quelles limites ? quelles optimisations ?) et sous l’angle opérationnel (pour qui ? pour quels usages ? comment assurer une adoption simple mais sécurisée ?).

Cette démarche est emblématique de l’ambition du groupe : ne pas consommer la technologie, mais la comprendre pour en tirer une vraie valeur métier. Et c’est exactement dans ce cadre que Cellenza intervient.

Nous réalisons un travail d’ingénierie et de conseil :

• décortiquer les Data Agents pour en comprendre les ressorts internes ;
• tester leurs capacités avec les jeux de données du groupe ;
• définir les premiers scénarios concrets : analyse de performance commerciale, support aux équipes opérationnelles, automatisation de tâches analytiques récurrentes… ;
• identifier les prérequis d’adoption à l’échelle du groupe ;
• proposer une trajectoire réaliste d’industrialisation.

Ce travail ouvre des perspectives enthousiasmantes : une donnée plus accessible, des analyses plus rapides, une démocratisation accrue de la BI, et une capacité nouvelle à créer de la valeur immédiate.

Les Data Agents ne sont pas seulement une fonctionnalité supplémentaire : ils représentent un nouveau mode d’interaction entre les équipes RAJA Group et leur patrimoine data.

C’est une évolution profonde, structurante, et que RAJA Group aborde avec lucidité, ambition et enthousiasme — toujours avec le soutien de Cellenza pour assurer des choix éclairés, responsables et alignés sur leur trajectoire data.

Pour aller plus loin — la vidéo du projet

https://www.youtube.com/watch?v=J90Lkrmda18&t=71s

En bref — ce qu’il faut retenir

• Une trajectoire data construite sur mesure pour RAJA Group.
• Une évaluation réaliste démontrant que Fabric correspondait parfaitement à l’organisation du groupe.
• Un moteur d’intégration permettant d’ingérer 26 ERP en trois mois.
• Une courbe d’apprentissage remarquable des équipes RAJA Group.
• Le Platform Engineering comme ADN Cellenza.
• Des arbitrages maîtrisés malgré un produit en pleine évolution.
• Une plateforme désormais orientée IA, Data Agents et transformation des usages.

L’article Comment RAJA Group a construit une plateforme data unifiée avec Microsoft Fabric est apparu en premier sur Le blog de Cellenza.

En effet, jusqu’ici, nous avons créé des Gateways selon nos besoins, et nous avons pu voir qu’il était facile d’ajouter des instances de celles-ci.

Toutefois, comme pour tout objet facile à déployer, il peut être souhaitable d’en limiter le nombre.

C’est à ceci que nous allons réfléchir dans cet article.

L’agenda :

• Scénario pour une Gateway partagée
• Configurer des HTTPRoutes et des Gateways pour plusieurs namespaces
• Configurer l’usage de Secrets pour les Gateways sur plusieurs namespaces
• Conclusion

1. Scénario pour une Gateway partagée

1.1. Réflexion sur le besoin d’une Gateway partagée

Jusqu’ici, comme nous l’avons évoqué en introduction, nous avons eu une approche distribuée dans l’usage de la Gateway API. C’est-à-dire que pour chaque périmètre, comme par exemple une application, nous avions une instance de Gateway dédiée, à laquelle étaient associées des HTTPRoutes, selon le besoin d’exposition de l’application.

Bien que cela fonctionne sans problème, cette approche distribuée ne capitalise pas sur le modèle Role-Based de la Gateway API, et donne probablement trop de responsabilités à une équipe qui gèrerait uniquement son application.

Si l’on part du postulat que le namespace représente une frontière de sécurité une fois les configurations RBAC souhaitées appliquées, déployer aussi bien la Gateway que la HTTPRoute n’est probablement pas souhaitable d’un point de vue sécurité. Après tout, la possibilité de créer une Gateway dans un Cloud-managed Kubernetes est équivalente à pouvoir créer un service exposé sur Internet.

Du point de vue de la GatewayClass, par sa nature, la ségrégation par namespace n’aura pas d’impact sur la capacité d’une équipe à utiliser une classe plutôt qu’une autre.

En revanche, la Gateway est une ressource dite namespaced, et dans une approche segragation of duties, il fait sens de déployer celle-ci dans un namespace distinct de l’application, dont le management serait confié à une équipe différente, typiquement une équipe d’opérateurs de cluster, vs des équipes responsables d’applications, comme indiqué sur le schéma.

On peut imaginer une organisation des ressources de la Gateway API comme ci-dessous :

• Un namespace, géré par des opérateurs de cluster, contenant la Gateway partagée, exposée sur le réseau externe.

• Des namespaces gérés par des responsables d’applications, contenant les ressources associées à l’application, et notamment la HTTPRoute requise pour l’exposition.

Rappelons que nous pouvons ajouter des annotations applicables sur le Service sous-jacent à la Gateway pour faire de celle-ci une Internal Gateway.

En prenant ce point en compte, on pourrait envisager la mise en place d’admission controller qui contrôleraient ou forceraient l’application de la section spec.infrastructure.annotations sur une instance de Gateway. Mais nous garderons ce sujet pour un autre article.

Enfin, à propos de l’usage de TLS, ce qui est absolument un prérequis pour le monde réel, nous pouvons voir que le certificat est référencé au niveau de la Gateway.

On remarque au passage l’existence d’un paramètre namespace dans la section certificateRegs, ce qui nous permet également d’envisager l’usage d’un namespace dédié pour les Secrets associés aux certificats permettant la configuration TLS. Auquel cas, il s’agirait encore d’un namespace géré par une équipe d’opérateurs de cluster, voire d’une équipe SecOps en charge de la gestion des certificats.

1.2. Un mot sur l’environnement de lab

Avant de nous plonger dans le cœur de notre sujet, un mot sur l’environnement de lab utilisé dans cet article.

En lieu et place d’un cluste AKS, nous utiliserons un kubernetes single node de type kubeadm, créé à l’aide de Vagrant.

Le VagrantFile est défini comme ci-dessous.

Un repo Github est disponible pour les « jusqu’auboutistes » qui voudraient manipuler eux-mêmes.

La GatewayClass dédiée suivante est créée.

Avec la CRD Cilium associée pour permettre l’usage d’un service NodePort, en l’absence d’un LoadBalancer disponible dans notre environnement local.

Pour simuler une application, nous utilisons un Deployment basé sur nginx, customisé avec une Configmap dans la configuration du Pod.

Exposer cette application, avec une approche distribuée nécessiterait la création d’une Gateway

et d’une HTTPRoute

Puisque nous sommes sur un cluster single-node, nous nous appuyons sur la gateway-class-config pour faire de notre Service sous-jacent à la Gateway un NodePort.

Si la Gateway est bien configurée pour un accès externe, nous obtenons un résultat similaire avec la commande curl.

Cependant, nous ne sommes pas à ce stade dans une approche partagée.

2. Configurer des HTTPRoutes et des Gateways sur plusieurs namespaces

2.1. Observation des propriétés de la Gateway

Pour commencer, étudions un peu les spécifications de la Gateway API.

L’on peut trouver dans la description de spec.listeners un paramètre appelé allowedRoutes, qui contient un champ namespaces. Sa valeur par défaut, comme affiché dans le tableau ci-après est Same, ce qui signifie donc que les HTTPRoutes acceptées par une Gateway par défaut sont celles dans le même namespace.

En suivant les liens de la documentation, on trouve ensuite les valeurs acceptées pour ce champ namespaces.

Ceci étant vu, créons à présent une nouvelle Gateway, dans son propre namespace.

On obtient les objets suivants après création.

En mettant à jour notre HTTPRoute créée précédemment, de la manière suivante :

On obtient le statut suivant.

Ce qui est prévisible, puisqu’à ce stade, nous n’avons pas modifié la valeur par défaut du paramètre allowedRoutes. Modifions notre Gateway pour qu’elle accepte les HTTPRoutes depuis tous les namespaces.

Une fois la modification faite, le statut de notre HTTPRoute passe à Accepted.

Et une commande curl nous permet d’accéder à notre Service derrière la Gateway.

Toutefois, autoriser tous les namespaces est peut-être un peu trop. Voyons comment utiliser le paramètre Selector afin d’être plus sélectif sur les namespaces cibles.

Le namespace gundam contient les labels ci-après.

Nous pouvons donc modifier notre Gateway comme ci-après pour cibler uniquement ce namespace.

Le statut de notre HTTProute ne change pas, puisqu’elle remplit toujours les conditions requises par la Gateway.

Ajoutons une nouvelle application, dans un autre namespace appelé demoapp.

Ainsi que sa HTTPRoute associée.

Le statut nous indique ce que l‘on attend, à savoir que la HTTPRoute n’est pas acceptée en l’état par la Gateway.

Pour configurer la Gateway pour accepter une liste de namespaces, on doit comprendre que par défaut, le champ matchLabels utilisé agit comme un AND. Ce qui signifie qu’ajouter d’autres namespaces comme ci-après indique à la Gateway de n’accepter que les HTTPRoutes dont les namespaces ont tous les labels spécifiés. Ce qui n’est pas possible dans notre cas, où nous utilisons un label reprenant le nom de chaque namespace.

Pour utiliser l’équivalent du OR dans un yaml kubernetes, nous utilisons la syntaxe suivante.

De cette manière, nous pouvons sélectionner plusieurs namespaces en nous appuyant sur le label kubernetes.io/metadata.name et en spécifiant une liste de valeurs acceptées.

Nous savons à présent comment gérer une Gateway partagée. Passons maintenant à la gestion du TLS.

3. Configurer l’usage de Secrets pour les Gateways sur plusieurs namespaces

Dans le cadre de la Gateway API, le certificat est géré au niveau de la Gateway. Le champ listerneters[].protocol doit être configuré avec la valeur HTTPS et le listeners[].port avec 443.

De plus, la section tls contient les informations relatives au certificat.

Une Gateway configurée avec un listener utilisant tls avec un Secret ressemble à ceci.

Référencer le Secret de cette manière implique que celui-ci est dans le même namespace que la Gateway, comme indiqué dans l’extrait de la documentation ci-après.

Pour réaliser nos tests, nous allons créer un namespace supplémentaire, et recréer le Secret associé à notre certificat dans ce même namespace.

Puis nous ajoutons le champ namespace dans le listener de la Gateway.

En regardant le statut de notre HTTPRoute, nous voyons que la référence à notre certificat n’est pas autorisée.

Ce à quoi nous nous attendions. Il nous faut utiliser un autre objet de la Gateway API : le ReferenceGrant.

Cet objet permet de spécifier quels objets peuvent faire références à quels autres objets. Concrètement, quels Secrets une Gateway peut utiliser.

Dans notre cas, on ajoute donc un ReferenceGrant dans le namespace de notre Secret, et indiquons que celui-ci peut être référencé par la Gateway dans le namespace ciliumgateway.

Une commande curl nous permettra à présent d’atteindre avec succès nos applications exposées derrière notre nouvelle Gateway partagée, avec un certificat référencé dans un Secret.

Il est à présent temps de conclure.

Conclusion

Toujours dans l’usage de la Gateway API, nous avons cette fois ci exploré la mise en œuvre et l’usage d’une Gateway partagée.

Il ressort que l’on peut sans trop de difficultés définir quels namespaces peuvent être autorisés à utiliser une Gateway.

Il est également possible de séparer la gestion des Secrets utilisés pour les certificats et le trafic TLS en s’appuyant sur un ReferenceGrant.

L’ensemble de ces fonctionnalités étant en GA dans la Gateway API, il reste à présent à sélectionner un provider de Gateway API pour pouvoir mettre en œuvre tout ceci et sortir de l’Ingress Controller.

L’article Considérations pour une Gateway partagée est apparu en premier sur Le blog de Cellenza.

Dans un article précédent, l’attention était porté sur la GatewayClass, et la Gateway, deux objets de l’API de la… Gateway API. L’analyse s’est arrêtée avant de réellement répondre à la question de l’exposition d’application. 

Ce nouvel article, poursuit l’exploration des objets relatifs à la Gateway API et nous attaquons plus précisément comment exposer les applications, avec la HTTPRoute. 

L’agenda :  

• Introduction à la  HTTPRoute 

• Ajouter la prise en charge de TLS 

• Conclusion 

Pour rappel,  une GatewayClass, et quelques Gateways ont été crées 

Ce qui a ppermisd’identifier la possibilité de passer des annotations au Service kubernetes créé avec la Gateway, à travers la propriété spec.infrastructure.annotations. Bien qu’il soit possible, dans le cas de la Gateway API Cilium, d’utiliser la crd spécifique pour customiser la GatewayClass, nous avons finalement utilisé la propriété au niveau de la Gateway. 

A ce stade, le manifest yaml de laGateway  prends la forme suivante 

Et nous utilisons les capacités d’Azure pour avoir un load balancer de type internal avec un manifest comme ci-dessous :

A présent, regardons comment effectivement gérer l’exposition de nos applications.

1. Introduction à la HTTPRoute

1.1. Les bases

L’exposition d’application dans Kubernetes est donc réalisée avec un objet appelé HTTPRoute.

Considérons une application basée sur un simple Deployment, ainsi qu’un Service :

Avec un Service de type ClusterIP, l’application n’est accessible que depuis l’intérieur du cluster.

Ajoutons une HTTPRoute.

Dans la section hostnames,un nom d’hôte doit être spécifié et résolvable d’un point de vue DNS. Dans le cas présent, un enregistrement est utilisé sur une Azure DNS zone. Cette étape n’est pas détaillée, puisque c’est un peu hors sujet.

Depuis un navigateur, le résultat est le suivant.

Ajoutons à présent quelques services à notre application, et voyons comment nous pouvons gérer cela.

1.2. Gestion de path avec la HTTPRoute

Avant de d’aborder dans ce sujet, prenons un peu de recul.

Avec un Nginx Ingress Controller,pour exposer, disons, 3 services,

un Ingress est défini de la manière suivante :

Sous réserve que les services existent, (et les deployments associés), lacommande curl devrait produire le résultat suivant

Mais la partie la plus intéressante ici est l’annotation ‘nginx.ingress.kubernetes.io/rewrite-target: /’ qui, comme on peut le supposer, ré-écrit les path depuis l’ingress vers le path ‘/’.

Tentons d’obtenir un résultat similaire avec une HTTPRoute.

Quelques deployments et services supplémentaires ont été crées.

L’objectif est d’exposer l’application barbatos via une HTTPRoute. une règle supplémentaire est ajoutée dans la section spec.rules.

Est-ce que cela fonctionne ?

Une réponse Not Found est obtenue d’un pod nginx constituant l’application. Ce qui est au demeurant logique, puisque qu’aucune ré-écriture du path n’a été spécifié. Le trafic est donc dirigé vers les pods de l’application sur le path /barbatos, alors que les pods en question ne servent que le path ‘/’.

Il est possible de confirmer cette affirmation en regardant les logs du pod correspondant.

La documentation de l’API de la HTTPRoute est consultée afin de trouver une solution.

Dans la section spec.rules, nous avons déjà ajouté une section matches, qui contient notre path cible.

La documentation de la HTTPRoute, mentionne l’existence d’une section filters qui peut être ajouter. Plus spécifiquement, le type URLRewrite présente un intérêt particulier.

Dans notre cas, nous allons donc utiliser ces propriétés pour modifier notre path avec :

• Un type avec la valeur ReplacePrefixMatch
• La propriété ReplacePrefixMatch configurée avec la valeur ‘/’ pour remplacer le path de la HTTPRoute vers le path ‘/’ sur le container.

Ce qui nous donne le résultat ci-après.

Et une HTTPRoute fonctionnelle sur l’url http://gundam.app.teknews.cloud/barbatos.

Le lecteur attentif (ou l’utilisateur d’Ingress expérimenté) aura remarqué que la configuration pour la ré-écriture du path est ici gérée pour chaque backend. Ce n’était pas forcément le cas avec un Ingress Controller, qui s’appuyait sur des annotations au niveau de l’Ingress, comme pour Nginx avec ‘nginx.ingress.kubernetes.io/rewrite-target: /’ que nous avons utilisé plus haut.

On peut donc noter que si la configuration de rewrite est peut etre un peu plus complexe, elle permet d’être également plus granulaire que dans le cas d’un Ingress.

Avant de passer à la gestion du TLS, observons la notion de gestion du poids.

1.3. Gérer le poids avec une HTTPRoute

Cette fonctionnalité a été abordé dans un article précédemment : la HTTPRoute peut nativement gérer le poids entres différents backend.

En recherchant dans la documentation, nous pouvons trouver la propriété spec.rules.backendRefs.weigh.

En transposant cette propriété dans une HTTPRoute, nous obtenons une configuration comme ci-après.

L’équilibrage se vérifie à l’aide d’une simple commande bash.

Ici,  la répartition de poids est d’environ 50/50.

En modifiant la configuration comme ceci :

La répartition devient beaucoup plus déséquilibrée comme attendu par les poids des backends respectifs.

Le sujet est à présent terminé. Passons à la gestion de TLS

2. Ajouter la prise en charge de TLS

2.1. Considérations pour l’usage de TLS avec la Gateway API

Comme pour les parties précédentes,  la documentation de la Gateway Api sert de référence

Depuis le point de vue de la Gateway, :

• La connexion downstream, qui a lieu entre le client et la Gateway
• La connexion upstream, qui a lieu entre la Gateway et le Service en backend.

De ce point de vue, la gestion de la connectivité avec TLS, plus exactement avec HTTPS, est limitée, dans le cas de la HTTPRoute, a une terminaison TLS au niveau de la Gateway.

On notera que ce n’est pas l’unique scenario, comme le résume le tableau ci-après.

Dans cette section, nous nous limiterons toutefois à l’usage de la HTTPRoute et donc au scénario de terminaison TLS sur la Gateway.

Note : On utilisera ici TLS ou HTTPS de manière interchangeable, bien que les deux ne soient pas tout à fait équivalent. Ici, TLS avec HTTPRoute est forcément avec HTTPS.

Regardons à présent comment effectivement configurer HTTPS sur notre HTTPRoute.

2.2 Configuration de HTTPS

La configuration TLS est réalisée en premier lieu au niveau de la Gateway.

La documentation de la Gateway foiurnit des informations sur le paramètre spec.listeners.tls.

Puis sur l’objet enfant spec.listenrers.tls.certificateRefs.

Ce qui permet de définir une configuration comme ci-dessous :

Dans le cas présent, le secret a été créer à l’aide de kubectl :

Une fois les objets kubernetes créés, une Gateway et une HTTPRoute sont disponibles.

A l’aide de curl, on peut vérifier la connectivité.

Voilà qui finalise notre exploration de la HTTPRoute.

Passons à la conclusion.

Conclusion

Cette fois-ci, l’accent a été mis sur comment effectivement exposer une application à travers l’usage d’une Gateway et d’un HTTPRoute.

La gestion de certificat est définie au niveau de la Gateway, à travers un objet référent qui est jusqu’ici un kubernetes Secret.

Apparaît  également la mention de namespace dans les différents objets utilisés, ce qui laisse sous-entendre une prise en charge cross-namespace pour par exemple, des scenarios de Gateway et de certificat mutualisé.

Mais ce sera un sujet pour un autre article.

L’article Toujours à propos de la Kubernetes Gateway API est apparu en premier sur Le blog de Cellenza.

Depuis son lancement, Microsoft 365 Copilot divise. D’un côté, des promesses d’une révolution de la productivité. De l’autre, une certaine sinistrose : coûts élevés, résultats parfois décevants, ROI difficile à justifier. Chez Cellenza, nous accompagnons quotidiennement des organisations dans leur transformation digitale, et nous constatons un fossé entre le potentiel de Copilot et la perception qu’en ont les utilisateurs. 

Ce fossé provient souvent d’une méconnaissance des capacités réelles de l’outil. Trop d’entreprises déploient Copilot sans stratégie d’adoption, espérant une magie instantanée. La réalité ? Copilot est un outil puissant, mais qui nécessite de comprendre où et comment l’utiliser efficacement. 

Cet article propose un tour d’horizon pragmatique des fonctionnalités de Copilot application par application, avec des cas d’usage concrets. L’objectif : vous aider à identifier les gains rapides et à construire une stratégie d’adoption qui génère une vraie valeur. 

Sécurité d’abord : L’Enterprise Data Protection 

Avant même de parler de fonctionnalités, abordons l’éléphant dans la pièce : la sécurité et la confidentialité des données. C’est souvent la première objection (légitime) des DSI et RSSI. 

Microsoft a mis en place ce qu’on appelle l’Enterprise Data Protection pour garantir que l’utilisation de Copilot ne compromet jamais vos données sensibles : 

Les garanties fondamentales : 

Vos données restent VÔTRES 

• Aucune donnée d’entreprise n’est utilisée pour entraîner les modèles d’IA de Microsoft 

• Les prompts et réponses ne sont pas stockés ni utilisés pour améliorer les modèles 

• Zero data leakage : l’IA ne peut pas « fuiter » des informations d’un tenant à un autre 

Respect des permissions existantes

• Copilot ne contourne JAMAIS vos contrôles d’accès 

• Un utilisateur ne verra via Copilot que ce à quoi il a déjà accès 

• Les politiques de partage et DLP (Data Loss Prevention) restent actives 

Gouvernance et conformité 

• Intégration native avec Microsoft Purview pour auditer toutes les interactions 

• Logs complets des requêtes et réponses pour investigations si nécessaire 

• Conformité RGPD, ISO 27001, SOC 2 maintenue 

• Possibilité de définir des policies pour bloquer certains types de contenus 

Souveraineté des données 

• Les données restent dans votre région géographique 

• Pour l’Europe, le traitement se fait dans des datacenters européens 

• Pas de transfert vers des juridictions non conformes 

Cette protection s’applique à toutes les interactions avec Copilot, que vous utilisiez la version gratuite de Copilot Chat ou la version payante avec accès aux données Microsoft 365. 

L’écosystème Copilot : Gratuit vs Payant, que choisir ?

Microsoft propose deux niveaux d’accès à Copilot, et c’est important de comprendre la différence pour construire votre stratégie d’adoption. 

Copilot Chat inclus dans les licences : Déjà puissant pour démarrer 

Bonne nouvelle : Tous vos collaborateurs avec une licence Microsoft 365 commerciale ont déjà accès à Copilot Chat gratuitement, avec l’Enterprise Protection activée. C’est une excellente porte d’entrée pour découvrir l’IA au travail sans investissement supplémentaire. 

Ce que permet Copilot Chat gratuit : 

1. Synthèse et extraction d’informations Collez un email long, des notes de réunion ou un article, et demandez un résumé ou les points d’action. Idéal pour traiter rapidement l’information.

Exemple : Un manager colle le compte-rendu d’une réunion de 5 pages et demande : « Extrais les décisions prises et les actions assignées avec leurs deadlines » 

2. Traduction et reformulation Besoin de traduire un document ? De réécrire un texte dans un ton différent ? Copilot Chat le fait instantanément.

Exemple : « Traduis ce paragraphe en néerlandais avec un ton formel pour une communication corporate » 

3. Brainstorming et rédaction créative Génération d’idées, de noms de projets, de slogans, premiers drafts de contenus… Un partenaire créatif accessible à tous.

Exemple : « Propose 10 noms accrocheurs pour notre nouveau service de conseil en cybersécurité, avec pour chacun une tagline » 

4. Recherche et questions générales Copilot Chat accède au web en temps réel et peut répondre à des questions factuelles avec sources citées. C’est un moteur de recherche augmenté.

Exemple : « Quelles sont les tendances actuelles en matière de Change Management digital dans le secteur bancaire ? » 

5. Analyse de fichiers individuels et multi-fichiers Uploadez jusqu’à 3 fichiers (512MB chacun) et posez des questions dessus. Copilot peut analyser ces fichiers ensemble pour en extraire des insights. Limitation : 3 fichiers par période de 24h dans la version gratuite.

Exemple : Upload de 3 documents (budget, planning, compte-rendu) : « Compare ces trois documents et identifie les incohérences entre le budget prévu et les dépenses réelles mentionnées dans le compte-rendu » 

6. Assistance technique (formules, code, scripts) Besoin d’aide pour une formule Excel complexe ou un script PowerShell ? Copilot Chat peut générer des exemples ou débugger.

Exemple : « Écris une formule Excel pour calculer la moyenne pondérée en excluant les valeurs nulles » 

7. Productivité personnelle Création d’agendas, to-do lists, plans de projet structurés… Copilot devient votre assistant d’organisation.

Exemple : « Crée un plan de projet sur 3 mois pour déployer Microsoft 365 Copilot dans une entreprise de 200 personnes » 

Nouveauté 2024-2025 : Copilot Chat est désormais accessible directement dans Word, Excel, PowerPoint et les autres apps Office via un panneau latéral, même sans licence payante. L’assistant IA est toujours à portée de clic dans votre flux de travail. 

Avec une licence Microsoft 365 Copilot : L’IA connectée à vos données 

La licence payante débloque la vraie puissance : Copilot accède à vos données Microsoft 365. 

Les capacités exclusives : 

Accès au Microsoft Graph Copilot peut interroger vos emails, documents, réunions, chats Teams, etc. C’est la différence fondamentale. 

Exemple concret : « Résume tous les échanges avec le client Acme Corp des 2 dernières semaines et identifie les points bloquants mentionnés » 

Sans licence payante, vous devriez manuellement copier-coller ces informations. Avec la licence, Copilot les trouve et les synthétise automatiquement. 

Analyse multi-fichiers et cross-référencement La version gratuite analyse jusqu’à 3 fichiers ensemble. La version payante peut travailler sur plusieurs documents simultanément sans limite quotidienne et faire des corrélations avancées. 

Exemple : « Compare les budgets mentionnés dans ces 4 propositions commerciales et crée un tableau comparatif » 

Agents déclaratifs inclus Avec la licence payante, vous pouvez créer et utiliser des agents personnalisés grounded sur vos données d’entreprise, sans coût supplémentaire. Dans la version gratuite, seuls les agents basés sur le web sont disponibles. 

Intégration profonde dans les apps Au-delà du simple chat intégré, la licence payante active des fonctionnalités avancées dans chaque application: 

• Teams : Récap de meetings avec références aux passages spécifiques, résumés de canaux entiers 

• Outlook : Coaching email basé sur votre historique, priorisation intelligente contextuelle 

• Word : Génération de contenu à partir de vos fichiers SharePoint ou OneDrive 

• Excel : Analyse de données et aide à la création de formules, graphiques et mise en forme conditionnelle  

• PowerPoint : Création de présentations à partir de vos documents Word ou données Excel 

• OneDrive/SharePoint : Recherche sémantique dans toute votre bibliothèque documentaire 

Reporting, formation et adoption: Accès au Copilot Dashboard dans Viva Insights pour mesurer adoption et impact. Accès à la Copilot Academy dans Viva Learning et assistance à la création d’une communautée d’adoption de Copilot dans Viva Engage. 

L’écosystème Copilot : Une approche unifiée 

Que vous utilisiez la version gratuite ou payante, voici les composantes de l’écosystème : 

Copilot Chat 

Un assistant conversationnel sécurisé qui combine la connaissance du web et l’accès à vos données professionnelles. Accessible dans Teams, Outlook, Edge et l’application principale, il devient votre interface naturelle avec l’intelligence artificielle au quotidien. 

Copilot Search 

Une recherche en langage naturel qui interroge simultanément vos emails, chats, documents et données à travers Microsoft 365 et les services connectés. Fini les recherches par mots-clés approximatives : posez simplement votre question. 

Copilot Notebooks 

Un espace de travail dédié à la réflexion approfondie et à la résolution de problèmes structurés. Idéal pour les scénarios complexes comme la planification trimestrielle, le traitement de tickets de support ou la rédaction de documents stratégiques. Les notebooks conservent un historique des interactions pour assurer continuité et réutilisation. 

Copilot (Loop) Pages 

Des canevas interactifs qui transforment les réponses de Copilot en pages éditables et partageables. Un outil puissant pour le brainstorming collaboratif, la création de documentation ou de contenus en temps réel avec vos équipes. 

Copilot par application : Le guide pratique 

Note importante : Les fonctionnalités avancées décrites ci-dessous nécessitent une licence Microsoft 365 Copilot payante. Pour les utilisateurs avec uniquement Copilot Chat gratuit, le panneau Copilot dans les apps Office permet d’accéder aux fonctionnalités de chat (brainstorming, rédaction, analyse de fichiers individuels) mais sans connexion aux données Microsoft 365. 

Copilot dans Teams : Conseiller en temps réel et récapitulatifs intelligents 

Le défi : Réunions manquées, manque d’impact durant les meetings, fil de discussions interminables. 

Ce que Copilot apporte : 

• Conseiller durant le meeting : Copilot peut résumer les points clés en temps réel, identifier où les participants sont alignés ou en désaccord, suggérer des actions de suivi, et même tester la solidité des arguments présentés 

• Agent Facilitator : Prend des notes collaboratives en temps réel pour tout le groupe, gère le temps de parole, suit les objectifs du meeting, et capture automatiquement les décisions et points clés 

• Intelligent Recap : Fonctionnalité incluse dans Teams Premium et dans la licence Microsoft 365 Copilot, qui génère des résumés détaillés des réunions avec chapitres, actions, et références temporelles 

• Rattrapage instantané : Si vous rejoignez 5+ minutes en retard, Copilot vous propose de vous mettre à jour automatiquement 

Gain concret : 4-5h/semaine pour un chef de projet multi-projets qui génère automatiquement ses comptes-rendus et reste concentré sur le contenu plutôt que la prise de notes. 

Prompt exemple durant la réunion : 

« Identifie les faiblesses dans l’argument qui vient d’être présenté sur notre stratégie de pricing et propose des contre-arguments basés sur les données du marché » 

Copilot dans Outlook : Inbox intelligente 

Le défi : 80+ emails/jour, priorités noyées, réponses chronophages. 

Ce que Copilot apporte :
Identifie les 5 emails critiques avec explication du « pourquoi », génère des brouillons de réponse contextualisés, et transforme un email en invitation de réunion en un clic. 

Gain concret : 1h30/jour économisées sur la gestion email pour les profils commerciaux. 

Prompt exemple : 

« Rédige une réponse professionnelle mais chaleureuse pour décliner poliment cette demande et proposer une alternative » 

 Copilot dans Word : De l’idée au document 

Le défi : Partir de zéro sur des documents structurés. 

Ce que Copilot apporte :
Génère un premier draft complet à partir de notes brutes, de plusieurs documents sources, ou d’un simple brief. Transforme du texte en tableaux, résume des documents longs, répond à des questions sur le contenu. 

Gain concret : De 3h à 30 min pour une note de cadrage client complète. 

Prompt exemple : 

« À partir de ces notes de réunion, crée une proposition commerciale structurée avec contexte, objectifs, approche méthodologique et livrables. Ton professionnel et concis. » 

Copilot dans Excel : Analyse en langage naturel 

Le défi : Formules complexes inaccessibles, analyses qui prennent des jours. 

Ce que Copilot apporte :
« Identifie les 3 produits avec la plus forte croissance et les 3 en déclin, analyse les facteurs saisonniers, et génère un dashboard visuel » – et c’est fait. Génère formules, détecte tendances, crée visualisations. 

Gain concret : De 2 jours à 30 minutes pour une analyse trimestrielle complète. 

Prompt exemple : 

« Analyse ce tableau de ventes. Identifie les produits les plus performants, calcule le taux de croissance mensuel, et crée un graphique comparatif » 

Copilot dans PowerPoint : Présentations en minutes 

Le défi : Créer des slides professionnelles prend des heures. 

Ce que Copilot apporte :
Génère une présentation complète (structure, contenu, visuels, notes) à partir de vos documents Excel/Word existants. Ajuste design et ton automatiquement. Tout en utilisant les modèles officiels de votre société. 

Gain concret : Présentation COMEX de 15 slides créée en 20 minutes au lieu de 3 heures. 

Prompt exemple : 

« Crée une présentation de 10 slides présentant notre nouvelle stratégie produit à partir de ce document Word. Style visuel moderne, ton inspirant. » 

Copilot dans OneDrive : Comparaisons multi-documents 

Le défi : Comparer manuellement plusieurs documents longs. 

Ce que Copilot apporte :
Compare jusqu’à 5 fichiers simultanément : « Compare ces 4 propositions sur prix, délais, garanties et expérience. » Résultat structuré en 2 minutes. 

Gain concret : Journée d’analyse comparative réduite à 15 minutes. 

Prompt exemple : 

« Compare ces trois documents de spécifications et identifie les exigences communes et les différences majeures » 

Copilot dans SharePoint : Sites auto-générés 

Le défi : Créer un site complet prend 2 jours. 

Ce que Copilot apporte :
Génère un site branded complet (structure, navigation, contenu) à partir de vos documents existants. Site d’onboarding RH créé en 2 heures au lieu de 2 jours. 

Les agents déclaratifs : Personnaliser Copilot pour votre métier 

Au-delà des fonctionnalités natives, Microsoft 365 Copilot permet de créer des agents déclaratifs – des versions personnalisées de Copilot adaptées à vos besoins spécifiques. 

Qu’est-ce qu’un agent déclaratif ? C’est un Copilot configuré avec :

• Instructions spécifiques : « Tu es un expert en réglementation RGPD » 

• Actions personnalisées : Connexions à vos systèmes métier 

• Connaissances dédiées : Accès à des documents, sites, ou bases de données spécifiques 

SharePoint Agents : Chaque site SharePoint peut devenir un agent spécialisé. Par exemple : 

• Un agent « Juridique » qui connaît tous les contrats types 

• Un agent « Produit X » qui maîtrise toute la documentation technique 

• Un agent « Projet Y » qui centralise toute l’information projet 

Ces agents peuvent être partagés dans Teams pour que toute l’équipe bénéficie de cette expertise contextualisée. 

Copilot Connectors : Intégrez vos sources de données externes (CRM, ERP, bases de données métier) pour que Copilot raisonne sur l’ensemble de vos informations, pas seulement celles dans Microsoft 365. Chaque organisation reçoit 50 millions d’items de quota d’indexation sans coût supplémentaire. 

Mon Retour d’expérience terrain : 5 agents qui transforment mon quotidien 

Chez Cellenza, nous ne nous contentons pas de conseiller nos clients sur Copilot – nous l’utilisons intensivement en interne. En tant que Head of Change Management, j’ai créé plusieurs agents déclaratifs qui sont devenus indispensables à mon travail quotidien. Voici un aperçu concret de ce que les agents peuvent apporter. 

1. Adoption Strategist

Sa mission : Piloter la stratégie d’adoption de solutions Microsoft 365 

Ce qu’il fait : 

• Construit des feuilles de route d’adoption (phases, acteurs, indicateurs) basées sur des modèles éprouvés (ADKAR, M365 Adoption Maturity Model) 

• Identifie et structure des KPIs d’adoption pertinents 

• Traduit les données d’usage en insights stratégiques pour les sponsors et la direction 

• S’adapte à la culture client (banque, industrie, secteur public) 

Ce qu’il m’apporte : Au lieu de 4-5h pour créer un plan d’adoption de zéro, j’obtiens une base solide en 10 minutes que je personnalise en 1h. 

Gain estimé : 3-4h par projet × 12-15 projets/an = 45-60h annuelles

2. Communication Architect

Sa mission : Concevoir des communications claires et engageantes pour différentes audiences 

Ce qu’il fait : 

• Rédige des contenus de communication à fort impact (news Teams, posts Viva Engage, e-mails, slides sponsor) 

• Élabore des plans de communication complets (cibles, canaux, calendrier) 

• Crée des storytelling utilisateurs pour ancrer le message (« Avant/Après » la transformation) 

• Génère des briefs visuels et des templates de communication 

• Adapte le ton selon le canal et la culture organisationnelle 

Ce qu’il m’apporte : Pour chaque projet, je génère rapidement 15-20 communications de qualité plutôt que de partir de zéro à chaque fois. Réduction de 70% du temps de création. 

Gain estimé : 2h par communication × 20/projet × 12 projets = 480h annuelles  

3. Learning Experience Designer

Sa mission : Concevoir des formations efficaces et engageantes sur Microsoft 365 et Copilot 

Ce qu’il fait : 

• Crée des parcours de formation et supports formateurs complets 

• Produit des fiches pratiques, quiz, scripts de formation, capsules vidéos 

• Conçoit des modules pédagogiques adaptés selon les personas 

• Prépare des Q&A Live et anticipe les questions utilisateurs 

• Propose des méthodes de mesure d’efficacité (NPS, taux de complétion) 

Ce qu’il m’apporte : Un module e-learning complet généré en 1h au lieu d’une journée. Je passe ensuite 2h à personnaliser. 

Gain estimé : 5h par module × 8 modules/projet × 12 projets = 480h annuelles 

4. Change Network Coach

Sa mission : Mobiliser et accompagner les relais du changement dans l’organisation 

Ce qu’il fait : 

• Identifie les champions naturels et définit leur rôle 

• Conçoit des kits de communication et formation pour les relais 

• Propose des animations communautaires (Café AI, challenges, feedback loops) 

• Crée des systèmes de reconnaissance et valorisation 

• Suit la participation et l’impact du réseau de champions 

Ce qu’il m’apporte : Génération rapide d’idées et de contenu pour animer le réseau de champions : challenges, fiches de rôles, reconnaissances. 

Gain estimé : 3h/mois × 12 mois = 36h annuelles  

5. Use Case & Persona Builder

Sa mission : Identifier et structurer les cas d’usage métiers et créer des personas d’utilisateurs 

Ce qu’il fait : 

• Construit des matrices de cas d’usage structurées 

• Rédige des fiches personas détaillées avec besoins et comportements 

• Évalue la valeur métier et la fréquence d’usage de chaque cas 

• Propose des prompts Copilot métiers adaptés aux rôles 

• Priorise les quick wins selon un framework « Pain → Usage → Gain → KPI » 

Ce qu’il m’apporte : Préparation d’ateliers cas d’usage accélérée. Je pars d’une base concrète plutôt que d’une page blanche, rendant les sessions beaucoup plus productives. 

Gain estimé : 2h par atelier × 4 ateliers/projet × 12 projets = 96h annuelles 

Bilan de mes 5 agents 

Temps total économisé annuellement : 1 137 heures 

Temps d’investissement pour créer ces 5 agents : ≈ 2 heures 

ROI de ma démarche agents : Plus de 5 000% la première année 

Au-delà des chiffres, ces agents ont transformé ma façon de travailler : 

• Plus de créativité, moins de temps sur l’exécution : Je me concentre sur la stratégie et la personnalisation 

• Qualité constante : Les livrables respectent toujours les meilleures pratiques 

• Scalabilité : Je peux gérer plus de projets simultanément sans surcharge 

• Capitalisation : Toute mon expertise est codifiée et réutilisable 

A retenir : Les agents déclaratifs ne sont pas un gadget. Bien conçus, ils deviennent de véritables collègues virtuels qui démultiplient votre impact. Et le plus beau ? Leur création ne nécessite aucune compétence en développement, juste une bonne compréhension de votre métier et de vos processus. 

Stratégie d’adoption recommandée : De la découverte gratuite au déploiement payant 

Phase 1 – Découverte gratuite (Mois 1-2) : « Goûter à l’IA » 

• Objectif : Créer une culture IA et identifier les champions 

• Action : Déploiement de Copilot Chat gratuit pour tous 

• Formation : Ateliers découverte de 1h par département 

• Mesure : Usage volontaire, feedback qualitatif, identification des power users 

Bénéfices attendus : 

• Démystification de l’IA (plus de peur de l’inconnu) 

• Identification des besoins réels par département 

• Constitution d’une communauté d’early adopters 

• Validation de l’appétit pour l’IA sans investissement majeur 

Phase 2 – Pilote payant (Mois 3-5) : « Prouver la valeur » 

• Objectif : ROI démontré sur cas d’usage ciblés 

• Action : 20-50 licences payantes pour les champions identifiés 

• Formation : Formation approfondie + accompagnement individuel 

• Mesure : Temps économisé, qualité des livrables, satisfaction 

Cas d’usage pilotes recommandés : 

• Commerciaux : Récap meetings + propositions (gain : 5h/semaine) 

• Managers : Synthèse multi-sources + reporting (gain : 4h/semaine) 

• Support : Analyse tickets + documentation (gain : 6h/semaine) 

• RH : Rédaction annonces + onboarding (gain : 3h/semaine) 

Phase 3 – Déploiement optimisé (Mois 6+) : « Industrialiser » 

• Objectif : Maximiser le ROI avec allocation optimale des licences 

• Action : Extension aux départements/rôles à fort ROI prouvé 

• Formation : Programme continu + communauté de pratique 

• Mesure : Dashboard Copilot, KPIs métier, optimisation continue 

Règle d’or : Gardez certains utilisateurs sur la version gratuite si elle suffit à leurs besoins. Pas besoin d’une licence payante pour quelqu’un qui utilise principalement Copilot pour du brainstorming ou de la traduction ! 

ROI : Parlons chiffres 

Gains de temps documentés : 

• Réunions : 30 min économisées par réunion 

• Emails : 45 min/jour pour les profils à forte charge 

• Création de contenu : 60-70% de temps en moins sur premiers drafts 

• Analyse de données : Réduction de 50% du temps d’analyse Excel 

Pour un collaborateur à 70k€/an qui économise 5h/semaine, le ROI est positif dès 6 mois. 

Au-delà des chiffres : 

• Réduction de la charge cognitive et du stress 

• Plus de temps pour les tâches à valeur ajoutée 

• Amélioration de la qualité des livrables 

• Meilleure collaboration d’équipe 

Conclusion : De la technologie à la transformation 

Microsoft 365 Copilot n’est ni une baguette magique, ni un gadget marketé. C’est un outil puissant qui, utilisé intelligemment et accompagné d’une vraie stratégie de Change Management, peut transformer significativement la productivité et l’expérience de travail. 

La clé du succès ? Ne pas voir Copilot comme un projet IT, mais comme une transformation organisationnelle nécessitant vision claire, accompagnement humain, itération continue et culture d’apprentissage. 

Chez Cellenza, nous accompagnons nos clients dans cette transformation, de la définition de la stratégie d’adoption à la mise en place des programmes de Change Management, en passant par la création d’agents personnalisés et l’optimisation des processus métier. 

L’ère de l’IA au travail est là. La question n’est plus « faut-il adopter Copilot ? » mais « comment en tirer le maximum de valeur pour mon organisation ? » 

Vous souhaitez échanger sur votre stratégie d’adoption Microsoft 365 Copilot ? Contactez-nous pour un atelier de cadrage personnalisé. 

L’article Microsoft 365 Copilot : Au-delà du buzz, quelles valeurs concrètes ? est apparu en premier sur Le blog de Cellenza.

Faisant suite à notre dernier post à propos de l’exposition des applications sur Kubernetes,  ce nouvel article propose de creuser davantage ce sujet que nous avons effleuré : la Kubernetes Gateway API. 

 Nous commencerons par un aperçu des options disponibles pour implémenter cette Gateway API, puis nous nous concentrerons sur 2 objets de l’API : la Gateway Class, et la Gateway. 

 L’agenda :  

• Quelques Gateway API providers 

• A propos de la Gateway Class 

• A propos de la Gateway 

1. Quelques Gateway API providers 

Les discussions autour de la Gateway API ont débuté dans un article dont le but était de discuter des moyens disponibles pour l’exposition d’application. 

Comme mentionné dans la documentation Kubernetes, l’API Ingress est à présent gelée, et la Gateway API en est son successeur officiel. 

Toujours dans la documentation, une liste des implémentations de cette Gateway est disponible parmis lesquelles , et de manière non exhaustive :  

• Nginx Gateway Fabric 

• Traefik Proxy 

• Istio 

• Application Gateway for Containers 

• Cilium 

A l’exception Cillium qui est encore en beta, tous les autres providers de cette liste sont en GA. 

Il est également possible de mentionner Hashicorp Consul qui pourrait être une alternative intéressante. 

Pour utiliser une implémentation de la Gateway API, il est nécessaire de disposer de quelques CRDs à priori. Ces CRDs sont :  

• La Gateway Class 

• La Gateway 

• La Http Route 

Il convient également de mentionner les objets suivants :  

• La gRPC Route 

• La TLS Route 

• Le Referent Grant 

Il convient de noter, point important, que toutes ces CRDs ne sont pas nécessairement au même état dans leur cycle de vie (GA vs Beta…) 

Les informations détaillées sur ces CRDs sont disponibles sur le github repository dédié. 

 A noter que la version stable actuelle est 1.3. 

La présence des CRDs sur un cluster, peut être vérifié à l’aide d’une commande kubectl 

Une fois ce point validé, il est temps d’installer un Gateway provider. 

Dans le cadre de cet article, malgré le statut Beta de sa Gateway API, nous utilisons un cluster avec Cilium comme CNI et procédons à l’activation de la feature avec un argument additionnel.

Si l’installation est complète, après le redémarrerage des pods Cilium, une Gateway Class devrait être disponible. 

Pour l’installation d’un provider, malgré toute la qualité de la documentation Kubernetes, il est préférable de consulter la documentation dédiée du provider choisi afin, entre autres, de valider la version des CRDs suppportée par le provider. 

 Par exemple, à la date d’écriture de cet article, la documentation pour la Gateway API de Traefik mentionne un support des CRDs en version 1.2.1. 

Dans le cas de Cilium,  la version stable actuelle supporte la version 1.2.0. 

Le remier point d’attention consiste donc, à valider la version des CRDs supportée par le Gateway API provider. 

De fait, il faudra donc être particulièrement prudent si l’on souhaite faire co-exister 2 providers de Gateway AP. 

Ces premiers points vus, passons à présent à la Gateway Class. 

2. A propos de la Gateway Class 

2.1. Quelques concepts 

L’installation d’un provider de Gateway API fournit une première Gateway Class. Avec un cluster AKS et Cilium en BYO CNI, la classe suivante est disponible. 

L’affichage en yaml  fournit des informations importantes sur le statut de la Gateway Class. 

La section conditions doit afficher type: Accepted et status: « True ». 

La section spec contient le  controllerName qui spécifie le provider utilisé. Ici, nous notons la valeur io.cilium/gateway-controller.  

En se référant au schéma de l’organisation rôle-centrique de la gateway API, on note que la Gateway Class est gérée côté Infrastructure Provider 

Ainsi, un Infrastructure Provider est en théorie est capable de définir une classe pour le trafic public et une autre pour le trafic privé. 

Regardons à présent l’objet API dans la documentation, afin de déterminer quelles sont nos options pour configurer davantage une Gateway Class. Le premier niveau de paramètres contient les éléments suivants :  

La section parametersRef est utilisée pour des configurations spécifiques au provider, et peut renvoyer vers une CRD ou une configmap. 

Dans le cas de Cilium, il y a effectivement une CRD appelé CiliumGatewayClassConfig qui peut être utilisé pour donner des paramètres supplémentaires, spécifique à Cilium. 

 Examinons comment utiliser ces différents paramètres. 

2.2. Expérimentations avec la GatewayClass 

Une commande kubectl nous a permis précédemment d’identifier la GatewayClass Cilium par défaut. 

Pour créer davantage de GatewayClass, par exemple pour du trafic interne et externe les définitions ci-dessous peuvent être utilisées :  

Après application du fichier, nous obtenons 2 nouvelles GatewayClass. 

A ce stade cependant, rien ne permet de spécifier dans les futures Gateway si celles-ci devraient être privées ou publiques. 

Dans le cadre de Cilium, il est possible d’utiliser la CRD CiliumGatewayClassConfig mentionnée précédemment. 

La section spec de cette CRD, visible sur la documentation Cilium est comme suit :  

Il convient de noter que la ressource est namespaced, et que son nom court est cgccc. 

Cette CRD permet de manipuler le type de service. il est possible d’écrire la définition suivante pour changer le type de service des Gateway d’une classe donnée. 

Au passage, la documentation Cilium réfère des exemples avec un service de type NodePort, utile pour des sandbox local sans Cloud Controller Manager, mais pas avec du ClusterIP comme dans notre exemple.  

 D’autre part, pour faire un peu de lien avec notre plateforme Cloud (ici Azure), il n’y a pas au niveau de la GatewayClass de moyen de passer des annotations comme service.beta.kubernetes.io/azure-load-balancer-internal: « true » pour forcer des Gateway avec des services de type LoadBalancer mais utilisant un service Azure LoadBalancer Internal.  

La GatewayClass est un équivalent à l’IngressClass des ingress controllers, et on verra que les annotations sont plutôt gérées au niveau de la Gateway.  

A présent, l’étape suivante concerne Gateway.  

3. A propos de la Gateway 

3.1. Concepts de base de la Gateway 

Comme le schéma ci-dessous le représente, la Gateway est le premier élément auquel accède un client qui veut atteindre une application exposée dans un environnement Kubernetes. 

Tenant compte de cette représentation, ainsi que de l’organisation Role-Based de la Gateway API,les divergences avec le modèle Ingress deviennent plus claires. 

En effet, avec un Ingress Controller, un unique point d’accès a été défini (sous la forme d’un service Kubernetes finalement, toute la partie L7 étant prise en charge par le dit controller), alors chaque Gateway est un point d’accès, obtenu d’une ou plusieurs GatewayClass. 

 Ci-dessous une définition de Gateway, avec la GatewayClass Cilium par défaut. 

La création de cette Gateway entrainera la création d’un service correspondant, préfixé avec cilium–gateway-. 

À noter par ailleurs que l’on a bien un service de type LoadBalancer. 

Également, on remarque le paramètre metadata.ownerReferences qui indique la dépendance à une Gateway. 

Essayons à présent de customiser un peu notre Gateway. 

3.2. Utilisation d’une GatewayClass avec une configuration Custom 

Dans cette section, la CRD  

CiliumGatewayClassConfig présenté précédemment est réexaminée  

Une GatewayClass custom est disponible utilisant une CRD pour changer le type de service. 

Et la définition de Gateway associée. 

La Gateway attendue devrait avoir un service sous-jacent de type ClusterIP, sans valeur attribuée pour l’adresse externe. Toutefois, on se rend compte que ce n’est pas le cas. 

Dans ce cas spécifique, la CRD CiliumGatewayClassConfig  n’a pas donné le résultat escompté. 

Est-il tout de même possible d’obtenir une Gateway s’appuyant sur un Azure Internal Load Balancer ? 

Essayons d’éditer le service associé d’une Gateway, en ajoutant l’annotation appropriée,  

 Après un peu d’attente, le service est mis à jour et s’appuie sur un Internal LoadBalancer. 

Nous avons donc obtenu le résultat attendu, mais cela n’est pas très satisfaisant. Observons nos options en analysant un peu plus l’API correspondant à la Gateway. 

 3.3. Analyse de l’objet Gateway 

Comme pour la GatewayClass, la documentation de la Gateway API donne les détails de l’objet Gateway. 

Dans la section spec, la sous-section infrastructure, contient les paramètres AnnotationKey et AnnotationValue.  

 Une nouvelle Gateway peut être créer avec cette section infrastructure. 

Une Gateway est obtenue avec une adresse privée, et son service associé qui hérite de l’annotation passée. 

La Gateway créée est finalement de type interne, mais sa nature n’a pas été hérité de la GatewayClass. 

Faisons un petit résumé. 

Conclusion 

Nous avons vu un peu plus en profondeur les 2 objets de la Gateway API suivant :  

• La GatewayClass 

• La Gateway 

 La GatewayClass, comme pour l’IngressClass, est utilisé pour définir des propriétés qui seront héritées par les Gateway enfants. 

La Gateway n’a pas d’équivalent dans l’architecture Ingress Controller. Elle constitue le point d’entrée pour les applications qui sont exposées. Il est possible de partager des Gateway sur différents namespaces, mais ce sera un sujet pour une autre fois. 

De la même manière, les détails pour l’exposition d’une application, et notamment l’usage de la http Route, seront vu prochainement. 

L’article A propos de la Kubernetes Gateway API est apparu en premier sur Le blog de Cellenza.

L’importance croissante de l’automatisation et de la sécurité dans le déploiement de l’infrastructure 

Les pratiques DevOps ont profondément transformé la manière dont les équipes IT conçoivent, déploient et maintiennent leurs infrastructures. Dans un contexte où les environnements cloud sont de plus en plus complexes, dynamiques et interconnectés, l’Infrastructure as Code (IaC) s’impose comme un levier clé pour répondre aux enjeux de scalabilité, de fiabilité et de rapidité d’exécution. 

Mais automatiser ne suffit pas. Une pipeline CI/CD mal conçue peut introduire de nouveaux risques : erreurs de configuration, expositions de secrets, ou encore dérives entre l’état souhaité et l’état réel de l’infrastructure. C’est pourquoi la sécurisation, la traçabilité et la standardisation des chaînes CI/CD dédiées à l’IaC sont aujourd’hui incontournables pour garantir un déploiement maîtrisé et conforme aux bonnes pratiques de gouvernance cloud. 

Face à ces défis, de nombreuses organisations – y compris les plus avancées – adoptent des architectures CI/CD modulaires, sécurisées et évolutives, s’appuyant sur : 

• Terraform pour la gestion déclarative de l’infrastructure, 

• Azure DevOps pour l’orchestration des workflows, 
• Et Microsoft Azure comme environnement cible de déploiement. 

Objectif de l’article 

Cet article propose une démarche concrète et structurée pour concevoir et mettre en œuvre une pipeline CI/CD dédiée au déploiement d’IaC avec Terraform sur Azure, orchestrée via Azure DevOps. 

Vous découvrirez comment : 

• Comprendre les enjeux spécifiques d’une pipeline IaC 

• Identifier les erreurs fréquentes et les risques d’une automatisation mal maîtrisée 

• Définir une architecture robuste intégrant la sécurité, l’organisation des environnements et le contrôle qualité 

• Construire pas à pas une pipeline CI/CD modulaire, réutilisable et bien documentée 

• Adopter les bonnes pratiques de versioning, de gestion des secrets et de tests automatisés 

• Évaluer les choix techniques autour d’Azure DevOps : agents d’exécution, Service Connections, templates YAML, etc 

I- Comprendre les enjeux du CI/CD pour l’IaC 

​Problèmes fréquents : erreurs humaines, manque de validation, mauvaise organisation.

Déployer de l’IaC sans pipeline CI/CD revient à exécuter manuellement des scripts Terraform dans un terminal, souvent depuis des postes locaux. Cette pratique expose les projets à de nombreuses erreurs : oublis de paramètres, mauvaises configurations, fuites de secrets ou dérives entre l’infrastructure réelle et celle définie dans le code. 

Une pipeline CI/CD bien conçue permet d’automatiser les étapes critiques du cycle de vie IaC (init, validate, plan, apply), tout en renforçant la sécurité et la traçabilité. Elle réduit les erreurs humaines, standardise les déploiements et permet d’appliquer systématiquement des contrôles qualité via des tests, des validations et des revues de code. 

En parallèle, l’usage rigoureux d’un système de versioning comme Git est indispensable. Il permet de tracer chaque modification, de collaborer efficacement et d’assurer un alignement constant entre le code source et l’état des environnements. Sans cette rigueur, les projets s’exposent à des dérives : états désynchronisés, scripts modifiés localement sans historique clair, ou déploiements non audités. 

C’est la combinaison d’un repository Git structuré et d’une pipeline CI/CD robuste qui constitue le socle d’une approche IaC maîtrisée et alignée avec les exigences de gouvernance cloud. 

II-Préparer le projet IaC  

La qualité d’une pipeline CI/CD repose d’abord sur une base solide : la structuration du projet Terraform. Trop souvent négligée, cette étape conditionne pourtant la maintenabilité, la sécurité et la collaboration à long terme. 

Avant même d’écrire une ligne de YAML, il est essentiel de poser des fondations solides : organiser clairement le dépôt Git, anticiper la gestion multi-environnements, définir une stratégie de versioning, et centraliser les variables sensibles. Une organisation rigoureuse permet d’éviter bon nombre de pièges techniques ou organisationnels par la suite. 

II.I- Organisation du dépôt Git : structure par environnement et modules 

Dans une logique d’industrialisation, notamment sur Azure avec Terraform, une architecture modulaire et scalable s’impose. 

Les bonnes pratiques consistent à : 

• Séparer les modules Terraform dans un dépôt dédié, versionné, réutilisable sur plusieurs projets. 

• Créer un dépôt par projet ou par environnement, dit « consommateur », qui appelle dynamiquement les modules via des tags (ref=vX.Y.Z). 

Cette séparation permet de centraliser la maintenance des briques d’infrastructure (réseaux, bases de données, comptes de stockage, etc.), tout en laissant aux projets la liberté d’orchestrer leurs environnements selon leurs besoins spécifiques. 

Structure globale du dépôt IaC consommateur 

Voici la structure à adopter dans votre dépôt principal : 

Fichier d’entrée : azure-pipelines.yml et templating YAML 

Le fichier azure-pipelines.yml, situé à la racine du dépôt, constitue le point d’entrée de la pipeline CI/CD. Il référence un ou plusieurs templates YAML centralisés, généralement placés dans .azure/pipelines/, tels que stage.yml, où sont définis les jobs standards : init, validate, plan, apply. 

Cette approche modulaire facilite la mutualisation des pipelines entre projets et permet de centraliser les mises à jour, tout en garantissant la cohérence des bonnes pratiques sur l’ensemble des environnements. 

backend/ : gestion du backend Terraform 

Le dossier backend/ contient les fichiers de configuration .conf propres à chaque environnement. Ces fichiers définissent l’emplacement et les paramètres du backend distant Azure utilisé pour stocker le terraform.tfstate. 

Exemple de paramètres définis : 

• resource_group_name : groupe de ressources Azure contenant le storage account 

• storage_account_name : compte de stockage dédié au backend 

• container_name : conteneur Blob où sera stocké l’état 

• key : nom unique du fichier .tfstate par environnement 

Cette organisation permet : 

• Un verrouillage d’état fiable (state locking) évitant les conflits d’écriture 

• Une isolation stricte des environnements 

• Un suivi centralisé et sécurisé de l’état de l’infrastructure 

vars/ : centralisation des variables d’environnement 

Le dossier vars/ regroupe les fichiers .tfvars propres à chaque environnement (ex. dev.tfvars, prod.tfvars). Ces fichiers permettent d’injecter des valeurs spécifiques (noms, tailles, tags, etc.) tout en réutilisant une même base de modules. 

Avantages : 

• Reproductibilité des déploiements 

• Clarté dans la gestion des paramètres 

• Versioning centralisé des configurations 

Fichiers racine : exécution Terraform 

À la racine du dépôt, on retrouve les fichiers standards suivants : 

• main.tf : appelle les modules distants 

• variables.tf : déclare les variables attendues 

• providers.tf : configure le provider Azure 

• locals.tf : centralise les valeurs intermédiaires (tags, formats, concaténations, etc.) 

Exemple d’appel d’un module distant dans main.tf : 

L’utilisation de tags (ref=vX.Y.Z) permet de figer une version stable d’un module, garantissant traçabilité et compatibilité dans le temps.Cette architecture modulaire et templatisée offre plusieurs avantages : 

Architecture modulaire : un modèle éprouvé 

Cette organisation modulaire repose sur une séparation claire des responsabilités : 

• Le dépôt template contient uniquement les modules Terraform génériques. 

• Le dépôt projet orchestre les déploiements selon les environnements cibles. 

Avantages : 

• Industrialisation : mise à jour centralisée des modules 

• Traçabilité : chaque version de module est identifiable 

• Sécurité : séparation des responsabilités 

• Scalabilité : ajout d’environnements ou de modules simplifié 

II.II- Sécurisation des branches : stratégie Git, gestion des PR, approbation 

Dans un projet IaC, une erreur peut avoir des conséquences critiques : ressources supprimées, configurations erronées ou fuites d’informations. La mise en place de branch policies strictes est donc incontournable. 

Stratégie de branches recommandée 

Une stratégie Git claire permet d’aligner sécurité, collaboration et contrôle qualité. Voici une structure éprouvée : 

• main : branche protégée, contenant le code validé. Représente la source de vérité. Tout changement doit passer par une Pull Request (PR). 

• develop : branche intermédiaire servant à valider les workflows sur l’environnement de qualification. 

• Branches feature/ : utilisées pour introduire des modifications spécifiques, issues de develop. 

La branche main doit être protégée par une policy interdisant tout push direct. 

Politiques de validation 

Les branch policies dans Azure DevOps permettent de : 

• Lancer automatiquement la pipeline à l’ouverture de chaque PR 

• Imposer une revue par un ou plusieurs membres de l’équipe 

• Bloquer la fusion si la pipeline échoue ou si des critères qualité ne sont pas remplis 

• Exiger un lien avec une User Story ou un ticket pour chaque PR 

Cette démarche garantit la qualité du code, la traçabilité des décisions, et une gouvernance claire des modifications. 

II.III- Organisation des groupes de variables 

Plus l’infrastructure grandit, plus la gestion des variables devient critique. Pour garantir lisibilité, maintenabilité et cohérence, chaque environnement dispose de son propre fichier .tfvars, regroupé dans un dossier vars/. 

Ce découpage permet de : 

• Centraliser les paramètres spécifiques (noms, tailles, régions, tags, etc.) 

• Réutiliser les mêmes modules avec des valeurs différentes 

• Faciliter les relectures et les validations 

Un simple appel avec le bon fichier .tfvars suffit à cibler un environnement spécifique sans modifier le code source. 

Validation conditionnelle des variables 

Pour fiabiliser les déploiements, il est essentiel d’intégrer des règles de validation dans les fichiers .tf. Cela permet de détecter rapidement les erreurs de saisie ou les valeurs non conformes dès le terraform plan. 

Exemple : 

​

Ce mécanisme évite des déploiements incorrects et renforce les standards internes, notamment dans les projets à grande échelle. 

Variable Groups dans Azure DevOps : une approche complémentaire 

En parallèle des fichiers .tfvars, les Variable Groups d’Azure DevOps permettent de gérer les paramètres et secrets directement depuis l’interface DevOps, sans modifier le code Git. 

Avantages : 

• Centralisation des variables utilisées dans plusieurs pipelines 

• Séparation du code et de la configuration 

• Intégration directe avec Azure Key Vault pour sécuriser les secrets 

• Modification facile sans ouverture de PR 

Exemple d’inclusion dans la pipeline YAML : 

​En une seule ligne, on charge toutes les variables nécessaires à un environnement donné. 

Utilisation dans le code Terraform :
Une fois injectées dans la pipeline, ces variables peuvent être passées à Terraform en tant que -var lors du plan ou apply : terraform plan -var « vm_size=$(VM_SIZE) » -var « region=$(REGION) ». Dans le code Terraform, il suffit alors de déclarer : variable « vm_size » {} et variable « region » {} 

Pourquoi combiner .tfvars + Variable Groups ? 

Cette double approche permet de tirer le meilleur parti des deux mondes :

Cette organisation prépare également l’infrastructure à évoluer facilement : duplication vers d’autres environnements, équipes ou clients sans refactorisation. 

III-Mettre en place les fondations Terraform 

Une fois le dépôt structuré et les variables bien gérées, il est temps de poser les bases techniques du projet : backend distant, provider, verrouillage d’état. 

Backend distant sécurisé 

Le fichier terraform.tfstate est le cœur du projet Terraform : il contient l’état réel de l’infrastructure. Le stocker en local expose à des risques majeurs (corruption, suppression, perte de synchronisation). 

La bonne pratique : configurer un backend distant dans Azure, basé sur un Storage Account. 

Avantages clés : 

• Collaboration fluide : état partagé entre tous les membres du projet 

• Sécurité renforcée : contrôle d’accès via RBAC, endpoints privés, règles NSG 

• Verrouillage automatique : évite les conflits lors d’exécutions concurrentes 

• Versioning natif : possibilité de rollback en cas d’erreur 

• Intégration CI/CD : état toujours synchronisé, que ce soit en local ou via pipeline 

IV-Construction de la pipeline 

IV.I-Définition d’une pipeline IaC efficace 

Une pipeline Infrastructure as Code (IaC) efficace doit répondre à plusieurs impératifs : 

• Automatiser les étapes clés du cycle Terraform : init, validate, plan, apply 

• Renforcer la sécurité via l’authentification OIDC, la gestion centralisée des secrets et le contrôle des accès 

• Gérer plusieurs environnements (développement, production, etc.) de manière isolée et cohérente 

• Intégrer des validations manuelles pour sécuriser les déploiements sensibles 

• Rester modulaire, lisible et facilement maintenable dans le temps 

Dans notre approche, la pipeline s’articule autour des éléments suivants : 

• Un fichier azure-pipelines.yml, agissant comme point d’entrée 

• Un template stages.yml réutilisable pour chaque environnement 

• Des groupes de variables partagés, facilitant la gestion des configurations 

• Un Storage Account Azure utilisé comme backend distant pour stocker et verrouiller l’état (tfstate) de manière centralisée 

IV.II- Étapes essentielles : init, validate, plan, apply 

​

Nous décomposons chaque étape de Terraform dans notre pipeline. La première étape de notre pipeline sera l’initialisation : 

• init 

Initialise le projet et configure le backend distant : 

• validate 

Permet de détecter les erreurs de syntaxe Terraform avant de générer un plan : 

• plan 

Génère le plan Terraform (stocké en .tfplan) : 

​

​apply 

Exécute le plan si validé : 

IV.III- Séparer les jobs / stages (validation, plan, apply…) 

Dans le fichier stage.yml, chaque étape clé du processus comme le plan ou l’apply est définie comme un stage distinct. Cette approche permet d’appliquer des politiques spécifiques à chaque étape (comme des approbations ou des délais d’attente), de mieux isoler et traiter les erreurs, et d’obtenir une pipeline plus modulaire, lisible et maintenable.  

Extrait de stage.yml : 

Et dans azure-pipelines.yml : 

Ce fichier YAML déclenche automatiquement la pipeline lorsqu’un changement est détecté sur les branches main ou dev. Il s’appuie sur le template stages.yml pour structurer les étapes, et injecte dynamiquement la valeur de l’environnement (dev ou prd). Cela permet de charger les bons fichiers .tfvars et les fichiers de configuration du backend, assurant ainsi un déploiement cohérent selon le contexte. 

Le fichier Yaml ressembleras à ça : Lien GitHub  

IV.IV- Gestion des validations manuelles (approbations) 

Avant d’exécuter un apply sur un environnement critique comme la production, il est essentiel d’ajouter une étape de validation manuelle. Cela peut être réalisé en configurant un environnement avec approbation dans Azure DevOps ou en ajoutant une tâche conditionnelle dédiée au sein de la pipeline. Cette précaution permet de garder un contrôle humain avant tout changement impactant. Voici comment l’on peut configurer cette étape : 

​Dans Azure DevOps, il suffit de configurer une approbation manuelle sur l’environnement GouvCloud-prod et le tour est jouer. 

V- Sécurisation de la pipeline 

Dans un contexte professionnel, sécuriser sa pipeline CI/CD est indispensable. Une mauvaise configuration peut exposer des identifiants, ouvrir des failles dans les infrastructures déployées, ou encore permettre des déploiements non autorisés. Cette section détaille les éléments clés pour sécuriser efficacement une pipeline Azure DevOps utilisée pour le déploiement Terraform sur Azure. 

V.I- Méthodes d’authentification via les Service Connections Azure DevOps 

Azure DevOps permet d’utiliser différentes méthodes d’authentification pour interagir avec Azure. Voici les trois principales : 

1. Service Principal classique (mot de passe / secret)

Cette méthode historique basée sur un ID d’application (clientId) et un secret (clientSecret) consiste à tout simplement créer un secret sur le Service et utilisé sa valeur afin d’avoir accès à des ressources. Son avantage c’est sa simplicité à mettre en place mais peu sécurisé. Et les inconvénients sont multiples :  

• Les secrets expirent (par défaut après 1 an). 

• Les secrets sont sensibles et doivent être stockés dans des variables sécurisées. 

• Impossible à utiliser avec OIDC. 

2. Service Principal avec certificat

Ce service utilise un certificat plutôt qu’un secret. L’avantage c’est tout simplement une meilleure sécurité que les secrets (certificats stockés dans Azure Key Vault) tandis que l’Inconvénient est de taille car elle rajoute de la complexité en terme de gestion. 

3. Service Principal fédéré (OIDC)

Azure DevOps utilise un jeton OIDC émis dynamiquement pour s’authentifier auprès d’Azure. Pas besoin de stocker un secret ou un certificat. Le jeton est court-lived, ce qui limite les risques de compromission. 

Avantages : 

• Sécurité renforcée : aucun secret à stocker dans la pipeline. 

• Gestion centralisée via Entra ID (anciennement Azure AD). 

• Compatible avec les bonnes pratiques DevSecOps. 

Cette approche est recommandée dans tous les contextes d’entreprise. 

V.II- Permissions, scopes et accès restreints 

Pour réduire les risques, il est essentiel de respecter le principe du moindre privilège (PoLP) lors de la configuration des permissions des Service Principals. 

Bonnes pratiques : 

• Créer un Service Principal par environnement (dev, preprod, prod). 

• Limiter les rôles au strict nécessaire (Contributor, Reader, etc.). 

• Éviter les rôles globaux tels que Owner. 

• Restreindre les scopes d’accès au niveau du resource group plutôt qu’au niveau de l’abonnement. 

• Documenter et auditer régulièrement les attributions de rôles (RBAC). 

V.III- Sécurité des agents d’exécution 

Dans une pipeline Azure DevOps, chaque job s’exécute sur un agent, une machine (virtuelle ou physique) chargée d’interpréter les étapes définies dans le YAML. On distingue deux types d’agents : 

• Microsoft-hosted : machines éphémères provisionnées automatiquement par Azure. 

• Self-hosted : agents que vous gérez vous-même, déployés sur votre propre infrastructure. 

Pourquoi opter pour un agent self-hosted ? 

Dans un cadre professionnel, notamment pour des environnements privés ou des ressources sensibles, les agents Microsoft-hosted atteignent vite leurs limites : 

• Pas d’accès aux ressources internes (VNet, Key Vault privé, etc.). 

• Pas de personnalisation possible (versions d’outils, configuration réseau). 

• Temps d’attente variable (agents partagés entre plusieurs organisations). 

Les agents self-hosted offrent une meilleure maîtrise de l’environnement d’exécution. Ils permettent de choisir librement les outils, les versions, et d’assurer une configuration adaptée, tout en garantissant un haut niveau de sécurité grâce à un contrôle total du réseau, des NSG et des accès. Ils permettent également une connectivité directe aux ressources internes sur Azure. 

Pour les héberger efficacement, la meilleure pratique consiste à utiliser une VM Scale Set (VMSS), qui regroupe des machines virtuelles identiques capables de s’adapter automatiquement à la charge. Cette solution assure une scalabilité dynamique, un réseau privé sécurisé, un environnement standardisé via image ou script personnalisé (Terraform, Azure CLI, etc.), et une cohérence d’exécution entre les agents, limitant ainsi les erreurs. 

Conclusion  

Construire une pipeline CI/CD dédiée à l’Infrastructure as Code avec Terraform n’est pas une simple formalité. C’est un engagement pour la qualité, la sécurité et la pérennité d’un environnements cloud. Tout au long de cet article, nous avons posé les fondations d’un projet IaC bien structuré. Le but n’est pas de complexifier, mais d’industrialiser intelligemment, afin de rendre les déploiements répétables, auditables et maîtrisés. 

L’article Construire un pipeline CI/CD sécurisée et optimisée pour déployer de l’IaC sur Azure est apparu en premier sur Le blog de Cellenza.

Après avoir abordé le sujet Azure Function sur Azure Container Apps, l’article se penche sur un autre scénario visant à héberger un GitHub Action Runner sur un conteneur. L’objectif de cet article est de documenter les étapes de la mise en œuvre, mais aussi de fournir un exemple d’implémentation fonctionnel. 

Utiliser Azure Container Apps pour héberger un GitHub Action Runner éphémère est une approche très intéressante à plusieurs titres :  

• Pas de machine virtuelle à maintenir, car nous utilisons une infrastructure managée par Microsoft 

• Limiter la maintenance au seul conteneur que nous allons construire de manière totalement industrielle 

• Conteneur instancié uniquement quand on en a besoin, donc une facturation limitée à la durée de vie du conteneur qui va exécuter notre GitHub Action workflow 

• L’infrastructure utilisée est directement connectée à notre Virtual Network, donc prête pour des déploiements en environnement privatisé 

Ce sujet est déjà documenté chez Microsoft : Deploy to Azure Container Apps with GitHub Actions. Cela fonctionne très bien, mais pour partir en production, on a besoin de travailler quelques sujets comme : 

• La construction de l’image de notre GitHub Action Runner 

• L’utilisation de l’authentification GitHub Apps en lieu et place d’un Personal Access Token (PAT) 

• Comment industrialiser ce processus  

La big picture 

Commençons par poser une vue d’ensemble. L’environnement Azure repose  sur Azure Container Apps Environment. Celui-ci disposera d’une User-Assigned Managed Identity lui permettant d’extraire un secret du Key Vault et d’instancier une image préalablement construite avec Azure Container Registry (ACR). L’Azure Container Apps Job instancié sera configuré pour exploiter le Scaler GitHub de  Keda (Kubernetes Event–driven Autoscaling). L’objectif est de pouvoir détecter qu’un GitHub Action Workflow est dans l’attente d’un GitHub Action Runner éphémère. C’est ce qui déclenchera l’instanciation du Azure Container Apps Jobs. 

Voila pour les grandes lignes. Maintenant rentrons dans le détail avec la mise en œuvre de l’infrastructure. Pour simplifier la mise en œuvre, tout est disponible sur ce repo GitHub : ContainerAppsJobGithubRunner 

Etape n°1 : Mise en œuvre de l’infrastructure 

L’infrastructure mise en œuvre est relativement simple. Elle se compose : 

• D’un Virtual Network dans lequel nous allons dédier un sous-réseau pour notre futur Azure Container Apps Environment 

• D’une User-Assigned identity qui sera utilisée par notre futur Azure Container Apps Environment pour « puller » l’image de notre GitHub Action Runner éphémère 

• D’une instance Azure Container Registry pour stocker l’image de notre conteneur 

• Une instance Azure Log Analytics Workspace pour collecter la télémétrie de notre Container Apps Environment 

• Une instance Azure Container Apps Environment qui va porter notre futur job 

• Une instance de Key Vault pour stocker les secrets que nous allons manipuler 

• Quelques rôles assignments afin que notre Azure Container Apps Environment puisse déployer notre job mais aussi lui mettre à disposition un secret issus de notre instance de Key Vault 

Pour simplifier la mise en œuvre, l’intégralité de ce déploiement est mise à disposition sous la forme d’un déploiement Bicep solution.bicep avec son fichier de réponse solution.json. Ne reste qu’à le déployer à l’aide de la commande New-AzSubscriptionDeployment 

New-AzSubscriptionDeployment -TemplateFile solution.bicep -TemplateParameterFile solution.json -location WestEurope 

Au terme de cette étape, tous les composants sont en place côté Azure, à l’exception de l’Azure Container Apps Jobs. Prochaine étape : la mise en place de l’authentification avec une GitHub App. 

Etape n°2 : Mise en place de l’authentification GitHub App 

À la première lecture de la documentation GitHub sur l’authentification GitHub App, on peut trouver le sujet un peu cryptique.Il s’agit d’une application que à déclarer, puis à installer au sein de notre repository GitHub. Dans le contexte de cet article, nous allons déclarer notre application GitHub App et l’installer dans notre Repository. La démarche est identique lorsqu’on voudra mettre en place au sein d’une organisation GitHub. Pour commencer, créer cette GitHub App : 

1. Connectez-vous à GitHub et allez dans votre profil pour sélectionner « Settings » 
2. Dans « Développer Settings », sélectionnez « GitHub Apps » 
3. Cliquer sur le bouton « New GitHub Apps » 
4. Choisissez un nom expressif pour votre GitHub Apps : « NPRD-ACARunner » 
5. Associez une description qui explique clairement à quoi va service cette GitHub App 
6. Vous pouvez fournir une URL fictive pour l’URL demandée dans notre contexte 
7. Assurez-vous que la case d’option « Expire user authorization tokens » est bien cochée

8. Désactivez la prise en charge de la fonctionnalité « Callback URL » 

      9.Dans la section « Repository Permissions » configurez les options suivantes :  

• Action: Read Only 

• Administration: Read Only 

• MetaData : Read Only

     10.Dans la section “Organization permissions, configurez les options suivantes 

• Actions – Read-only 

• Metadata – Read-only 

• Self-hosted Runners – Read & Write 

Selon que le déploiement se fasse dans le contexte d’une organisation GitHub ou d’un simple repository GitHub personnel, les permissions ne sont pas les mêmes, tout comme les URL sollicitées pendant l’initialisation de notre GitHub Action Runner éphémère. Une fois l’application créée, assurez-vous de bien conserver l’App ID puis générer une clé privée pouvant être utilisée que nous pourrons utiliser comme méthode d’authentification. 

L’application GitHub App est maintenant déclarée, il faut procéder à son installation. Elle peut être rendue disponible à grande échelle au niveau d’une organisation mais j’ai volontairement retenu de ne l’installer que dans mon projet GitHub. 

Lors de l’installation de l’application, un « Installation ID » sera généré, celui-ci est visible dans l’URL dans votre navigateur. Nous avons besoin de le conserver. 

Etape n°3 : Mise en place des secrets 

Lors de la mise en œuvre de GitHub App, nous avons récupéré des identifiants (GitHub AppID & GitHub Installation ID) ainsi qu’une clé privée. Pour les identifiants, j’ai choisi de les consommer directement dans Azure Container Apps comme variables d’environnements de notre futur conteneur.  

Cependant, pour la clé privée, une attention particulière est nécessaire. L’infrastructure déployée inclut une instance de Key Vault. Elle permettra d’y stocker notre clé privée. Seul Azure Container Apps y aura accès, il passera cette référence à notre futur conteneur.  

Il ne reste plus qu’à uploader le contenu du fichier contenant la clé privée comme secret : az keyvault secret set –vault-name <Key Vault Name> –name GitHubPEM –file <pem file> –output none 

Etape n°4 : Construction de notre GitHub Runner 

C’est en fait le sujet le plus compliqué. Pour construire cette image, j’avais trois possibilités :  

• Utiliser les images mises à disposition par GitHub. Cela fonctionne mais c’est un peu vide  

• Utiliser l’excellent travail d’autres : https://github.com/myoung34/docker-github-actions-runner 

• Construire son image soi même 

C’est cette dernière option que j’ai retenue car je voulais personnaliser les composants mis à disposition dans le GitHub Action Runner, jusqu’à personnaliser la version de chaque composant. En plus, il est essentiel de d’intégrer la prise en charge de l’authentification GitHub App. C’est ce point qui a nécessité le plus de travail.   

Etant donné que la construction de l’image est relativement chronophage (presque douze minutes), tout ce qui est nécessaire est présent dans le repository dans le répertoire Docker   du Repository Git mis à disposition avec cet article. Les commandes ci-dessous vont nous permettre d’identifier l’instance du service Azure Container Registry (ACR) mis à disposition, s’y connecter et de déclencher la construction de notre conteneur. 

1. az acr list –query [].name –output tsv 
2. az acr login –name <Nom de l’instance ACR précédemment identifiée> 
3. az acr build –registry <Nom de l’instance ACR précédemment identifiée> –image <Nom de l’instance ACR précédemment identifiée>.azurecr.io/runner_base: 2.325.0 . –build-arg ‘RUNNER_VERSION=2.325.0’ –build-arg ‘DOTNET_VERSION=9.0’ –build-arg ‘PS_VERSION=7.4.5’ –build-arg ‘AZACCOUNTS_VERSION=3.0.4’ –build-arg ‘AZKEYVAULT_VERSION=6.2.0’ –build-arg ‘AZSTORAGE_VERSION=7.4.0’ –build-arg ‘AZAPPINSIGHT_VERSION=2.2.5’ –build-arg ‘AZNETWORK_VERSION=7.10.0’ –build-arg ‘AZRESOURCES_VERSION=7.5.0’ –build-arg ‘AZ_TABLE_VERSION=2.1.0’ –build-arg ‘MS_GRAPH_VERSION=2.24.0’ –build-arg ‘MS_ENTRA_VERSION=1.0.1’ –build-arg ‘TERRAFORM_VERSION=1.10.0’ –build-arg ‘TERRAGRUNT_VERSION=0.72.2’ –build-arg ‘AZURECLI_VERSION=2.74.0’ –build-arg  ‘UBUNTU_LTS_VERSION=jammy’ 

Douze minutes plus tard, nous avons une image pour notre futur Runner GitHub Action. Le DockerFile mis à disposition inclus un grand nombre de variables pour personnaliser les versions des composants. Au moment de l’écriture de cet article, c’est la version 2.325.0 de l’image du GitHub Runner qui est disponible. Pensez à aller regarder quelle est la version la plus récente de disponible ici : https://github.com/actions/runner-images/releases. 

Une fois l’opération terminée,  la présence d’une nouvelle image dans Azure Container Registry peut être vérifié avec la commande suivante : az acr repository show –name <Nom de l’instance ACR précédemment identifiée>  –repository runner_base 

Maintenant, reste à expliquer comment va fonctionner l’authentification. Le fichier Dockerfile, mentionne la copie et du script entrypoint.sh. Il sera exécuté à chaque instanciation du conteneur. Pour écrire ce script, je suis parti de la documentation GitHub sur le sujet : Generating a JSON Web Token (JWT) for a GitHub App. Le script exploite la clé privée pour négocier un « Access Token » qui sera ensuite soumise à l’API de GitHub Runner registration, obtenant ainsi un « Registration Token » qui sera lui-même utilisé pour enregistrer le GitHub Runner éphémère.  

Selon qu’il s’agisse d’une organisation GitHub ou d’un simple GitHub Account, les URL ne sont pas les mêmes. Dans le contexte de cet article, je travaille sur mon repository personnel. Le tableau ci-dessous référence les URL qui seront nécessaires et comment les construire selon les scénarios : 

Note : Dans le contexte de cet article (et ne disposant pas d’une organization GitHub personnelle), ce sont donc les URL de mon Repo personnel GitHub qui sont utilisées. Pour un déploiement dans le contexte d’une organisation, il faudra adapter les variables dans le fichier acajob.bicep.   

 Le conteneur va exploiter les informations suivantes en tant que variables d’environnement : 

• APP_ID 

• PEM (référencé entant que secret Key Vault) 

• ACCESS_TOKEN_URL 

• REGISTRATION_TOKEN_API_URL 

• RUNNER-REGISTRATION_URL 

Etape n°5 : Déploiement de notre GitHub Runner 

Le déploiement est assuré par un déploiement Bicep acajob.bicep et son fichier de paramètres associés acajob.json. Pensez bien à actualiser ce dernier. La configuration du Azure Container Apps job comprend :  

• L’image à utiliser ainsi que la User-Assigned Identity qu’Azure Container Apps devra utiliser pour « Puller » l’image pour notre conteneur. 

• L’identifiant unique de notre GitHub Application ID 

• La référence du secret Key Vault contenant la clé privée obtenus lors de la création de notre GitHub Application 

• Les trois URL de GitHub (Registration Token API URL, Runner Registration Token API URL, Access Token API URL) 

• La configuration de Keda pour le Scaler GitHub 

Le déploiement est réalisé avec la commande ci-dessous :  

New-AzResourceGroupDeployment -ResourceGroupName RG-nprd-acarunner-1.0    -TemplateFile acajob.bicep -TemplateParameterFile acajob.json 

La seule subtilité de configuration concerne le stockage de la clé privée obtenue avec notre GitHub App. Celle-ci a été volontairement stockée dans un Azure Key Vault pour qu’elle ne soit pas directement visible dans la configuration du conteneur comme illustré ci-dessous.   

Pour que le conteneur puisse être instancié à la demande, reste encore à configurer Keda et plus particulièrement le scaler GitHub Runner. Le scaler a besoin d’un certain nombre de paramètres. Le point d’attention sera de ne pas être trop agressif au niveau des API de GitHub sous peine de rate limiting. C’est pour cette raison que j’ai retenu de dédier mon GitHub Action Runner à un seul et unique GitHub repo. Ici encore, c’est la référence du secret Key Vaultutilisé  pour passer la clé privée de GitHub App.  

Tester notre Github Runner éphémère 

Pour tester GitHub Action Runner, nous avons besoin d’un Workflow. Pour l’exemple en voilà un : demoRunner.yml. Comme on peut le voir ci-dessous, il est minimaliste, composé d’un seul job contenant quelques commandes pour mettre en évidence quelques composants intégré à notre conteneur. Sa seule particularité, c’est de demander son exécution sur un Runner de type « Self-Hosted ». C’est justement un des tags de notre GitHub Action Runner éphémère. 

Une fois ce GitHub Workflow déclenché, au niveau Keda, on peut suivre le bon déroulement des opérations avec une simple requête KQL :  

ContainerAppSystemLogs 

| where EventSource == ‘KEDA’ 

| where JobName == « githubactionrunner » 

Le Keda initialise correctement le Scaler et  est  mesure de détecter la présence de GitHub Action workflow en attente d’exécution pour déclencher l’instanciation du GitHub Runner.  

Au niveau de notre Container Apps Jobs,l’initialisation s’effectue correctement et les logs restent consultables.  

Au niveau GitHub, on peut constater que le GitHub Workflow s’est bien déclenché et a été exécuté depuis notre GitHub Action Runner éphémère. 

En agissant rapidement, il est possible deconstater la présence duGitHub Action éphémère. 

Pour finir, une fois le GitHub Workflow terminé, il sera posszible  de constater le bon fonctionnement de celui-ci avec une simple requête KQL comme illustré ci-dessous :  

ContainerAppConsoleLogs_CL 

| where Log_s contains « √ » 

Conclusion 

La mise en œuvre est un peu plus compliquée qu’avec un Personal Access Token (PAT) mais une fois l’intégration de l’authentification avec GitHub Apps, nous disposons d’un GitHub Runner éphémèrefacturé uniquement en fonction de la puissance CPU & consommation mémoire utilisées lors de l’exécution de vos GitHub Action Workflows. Avec quelques modifications au niveau du DockerFile, vous serez en mesure de rapidement développer un GitHub Action Runner répondant à vos besoins. 

Quelques lectures additionnelles 

Entre ma première lecture de l’article Deploy to Azure Container Apps with GitHub Actions et celui-ci, plusieurs itérations ont été nécessaires pour bien comprendre l’assemblage de tous les composants et les implications de l’utilisation de GitHub Apps comme méthode d’authentification. Je vous recommande les lectures suivantes :  

• Les runners GitHub : https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners 

• Base image for GitHub self-hosted Runners : https://github.com/actions/runner 

• Une excellente base de travail pour des runners GitHub : https://github.com/myoung34/docker-github-actions-runner 

• L’implémentation avec Azure Verified Modules : https://github.com/ethorneloe/azure-apps-jobs-github-runners, https://github.com/Azure/terraform-azurerm-avm-ptn-cicd-agents-and-runners 

• La documentation officielle de Keda sur la configuration des scalers : https://keda.sh/docs/2.17/scalers/github-runner/ 

• Comment la version 2.17 de Keda va résoudre certains problèmes rencontrés : https://github.com/microsoft/azure-container-apps/issues/1525 

L’article Héberger un GitHub Action Runner sur Azure Container Apps est apparu en premier sur Le blog de Cellenza.

1. Créer un workflow codeql.yml 
   pour analyser le code automatiquement via GitHub Actions et exporter les résultats au format SARIF. 
2. Configurer un fichier codeql-config.yml 
     afin de définir les chemins à inclure ou ignorer, sélectionner les packs de règles, et ajouter des queries personnalisées. 
3. Écrire des custom queries .ql avec métadonnées 
     en utilisant les propriétés telles que @problem.severity, @precision, @tags et @security-severity pour ajuster la sévérité et la pertinence des résultats. 
4. Utiliser les query-filters 
     pour réduire le bruit, exclure certaines règles peu précises ou recommandations, et concentrer l’analyse sur les résultats critiques.
5. Tester et interpréter les résultats
     en visualisant les alertes dans GitHub Security ainsi que dans les fichiers SARIF exportés, afin de valider que la configuration et les requêtes répondent bien aux besoins du projet 

I-Créer le workflow codeql.yml

Créer un fichier .github/workflows/codeql.yml. 
Ce fichier décrit les étapes du workflow GitHub Actions qui exécute CodeQL. Voici un example pour un projet C++ : 

Explication du fichier : 

uses: github/codeql-action/init@v3: cette étape installe et configure CodeQL en précisant le langage à analyser. Elle charge le fichier codeql-config.yml pour savoir quels dossiers à inclure/exclure et quelles règles (queries) à exécuter. 

uses: github/codeql-action/autobuild@v3: GitHub essaie de compiler automatiquement le projet. Pour les langages compilés (C#, Java, C++), CodeQL a besoin d’une compilation (build) obligatoire pour comprendre la structure de le code. Si l’autobuild échoue, on peut remplacer avec un build manuel (make, cmake, mvn, dotnet build, yarn build, etc.) 

uses : github/codeql-action/analyze@v3: cette action exécute l’analyse CodeQL avec les règles choisies. Les résultats sont exportés après, dans un fichier SARIF (ce fichier contient les vulnérabilités, leur sévérité et leur précision.) 

uses: actions/upload-artifact@v4: sauvegarde le fichier SARIF comme artefact téléchargeable du workflow. On peut aussi l’ouvrir dans GitHub Security ou bien l’importer dans un outil tiers (SonarQube…etc) 

II- Fichier de configuration codeql-config.yml 

Ce fichier permet de personnaliser ce qui est scanné et quelles règles sont utilisées : 

Explication du fichier 

On indique quelles queries CodeQL doit on exécuter pour notre projet : 

• security-extended : pack officiel GitHub avec plus de règles de sécurité (recommandé). 

• security-and-quality : ajoute en plus des règles de bonnes pratiques et de qualité de code. 

• ./github/codeql/queries/test-query.ql : la query custom, qui détecte par exemple l’usage dangereux de la fonction classique strcpy() dans du C/C++ 

1. Filtrer les résultats avec query-filters 

Les query-filters permettent de contrôler finement les résultats de CodeQL sans modifier les requêtes elles-mêmes. Concrètement, ils servent à exclure ou inclure certains résultats en fonction de critères comme : 

• problem.severity : exclure par exemple les warnings pour ne garder que les errors. 

• Precision : ignorer les règles de faible précision (low) pour réduire les faux positifs. 

• Tags : cibler uniquement certaines catégories (ex. security, correctness, etc.). 

Le fichier SARIF résultant, ne contient plus les severités filtrées (low, warning) 

III- Comprendre un fichier de requête CodeQL (.ql) 

Un fichier .ql est une requête qui décrit un pattern à détecter dans le code. Il est une sorte de langage déclaratif inspiré de SQL et de la logique, qui manipule les bases de données CodeQL générées à partir du code source (About CodeQL queries — CodeQL). 

On peut s’inspirer ou utiliser directement ces build-in queries via codeql/cpp/ql/src/Likely Bugs/Likely Typos/UsingStrcpyAsBoolean.ql at main · github/codeql)  

Exemple de requête pour détecter strcpy() : 

Explication du fichier : 

La première partie est la description du fichier .ql : 

• @name : le nom affiché dans GitHub Security. 

• @description : explication du problème. 

• @kind : type de résultat (problem, path-problem, etc.). 

• @precision: niveau de confiance (low, medium, high, very-high). 

• @problem.severity: sévérité (error, warning, recommendation). 

• @tags : classification pour filtrer ou relier à CWE, bonnes pratiques, etc. 

• @security-severity : score de 0.0 à 10.0 → traduit en Critical / High / Medium / Low dans GitHub 

1. Ensuite pour le reste du fichier : 
   • On importe la librairie CodeQL pour le langage C++ (CodeQL library for C and C++ — CodeQL) 
   • from FunctionCall call
     → on définit une variable call qui représente chaque appel de fonction trouvé dans le code C++. 
   • where call.getTarget().getName() = « strcpy »
     → on filtre uniquement les appels à la fonction strcpy. 
   • select call, « Avoid using strcpy… »
     → on retourne chaque appel détecté avec un message d’alerte. 

IV- Les Bonnes Pratiques au niveau Pull Requests 

Au-delà de la création des custom queries et de la configuration des workflows, il est essentiel de mettre en place des règles de protection sur les branches pour garantir que le code vulnérable ne soit jamais fusionné vers la branche principale, par erreur ou par un Bypass/Force merge de PR. 

RuleSets à activer dans GitHub : 

• Require status checks to pass : obliger le workflow CodeQL à réussir avant de permettre un merge. Il devient en mode « Required ». 

• Require branches to be up to date before merging → la PR doit être mise à jour avec la dernière version de la branche cible pour éviter d’intégrer du code non-scanné 

• Require code scanning results : forcer la présence des résultats CodeQL avec un : 

• Seuil de Security alerts: High or higher 

• Type d’alertes bloquantes : Errors ou bien All 

Cela signifie que si une alerte de sévérité High ou Critical est détectée, le merge sera bloqué jusqu’à correction. 

Avec ce ruleset, une PR ne peut pas être fusionnée tant que le workflow CodeQL n’a pas tourné et les alertes de sécurité de type High ou plus graves n’ont pas été résolues. 

Conclusion 

En résumé, les queries CodeQL personnalisées offrent une grande flexibilité : elles permettent d’aller au-delà des règles standard de GHAS, de répondre à des besoins métier spécifiques et de renforcer la détection de vulnérabilités selon le contexte du projet. 

L’article Optimiser vos analyses de sécurité GitHub avec des requêtes CodeQL custom est apparu en premier sur Le blog de Cellenza.

Prérequis : Databricks runtime 17.0 (June 2025 – Link), Databricks Unity catalog, accès aux tables system access. 

Introduction 

L’arrivée de Spark 4.0 marque un jalon important dans l’évolution du moteur Spark et amène son lot de nouveautés, parmi lesquelles la possibilité de faire des requêtes SQL récursives. 

Celles-ci ont plusieurs avantages : elles permettent de rendre vos scripts SQL plus lisibles, efficients, et sont un atout considérable pour vos projets analytics. Afin d’illustrer cette fonctionnalité et les éléments à prendre en compte au moment de son implémentation, nous allons partir d’un cas d’usage concret : l’extraction complète (c’est à dire avec les colonnes) du data lineage pour une table spécifique, à l’aide de la table système 

system.access.column_lineage, accessible depuis Unity Catalog (pour les workspaces où celui-ci est activé). 

Pourquoi un tel cas d’usage ? 

Simplement parce que les fonctionnalités de data lineage proposées par Databricks rencontrent aujourd’hui certaines limites. Pour bien comprendre, rappelons brièvement que le data lineage est une fonctionnalité d’Unity Catalog qui permet notamment de suivre le cycle de vie des données en traçant leurs origines, les transformations appliquées et leurs utilisations – bien sûr, tout cela de manière automatisée. 

Plusieurs outils sont ainsi proposés par Databricks pour exploiter le lineage 

Deux tables système : 

system.access.column_lineage (Lien) : permet de tracer les lectures/écritures au niveau des colonnes. 

  system.access.table_lineage (Lien): permet de tracer les lectures/écritures au niveau des tables. 

Le « Catalog explorer » – Interface utilisateur 

Un onglet »Lineage » est accessible lors de la sélection d’une table depuis le Unity Catalog. 

Une vue graphe du data lineage en sélectionnant une table. Une API REST. 

À ce jour, les limitations identifiées sont les suivantes 

Les tables système ne fournissent que les dépendances en amont et en aval dites directes (c’est-à-dire sous la forme source → target). Pour obtenir l’intégralité des dépendances, il est nécessaire d’exécuter plusieurs requêtes récursives. 

Les filtres et colonnes utilisés dans les jointures ne sont pas capturés si les colonnes sont absentes de la table finale. Cela est dû à l’absence de lien direct entre une colonne source et une colonne cible, ce qui peut entraîner une perte de visibilité sur la logique de transformation. 

La périodicité retenue pour la conservation des données de lineage est limitée à un an. 

Il n’y a pas de traçage des opérations de DELETE et UPDATE. Si un champ est renommé ou supprimé, il devient difficile à identifier dans les tables système sans une requête avancée. 

Ainsi, il peut être intéressant, dans certains cas, de disposer d’un outil permettant d’extraire le data lineage sur l’ensemble des dépendances d’une table spécifique. Le support des CTEs récursives (Common Table Expressions) va justement nous y aider. 

– Rappel rapide sur les CTE 

L’objectif de cet article n’est pas de faire une présentation exhaustive des CTEs récursives, mais voici les principales utilisations à garder en tête pour la suite : 

L’exploration des relations hiérarchiques. 

La construction d’arbres de dépendance, notamment de type parent-enfant (ex. : catégories). 

L’itération et la génération de suites numériques ou de séquences (par exemple, pour extraire chaque lettre d’un mot, etc.). 

Structure d’une CTE récursive 

Les CTEs récursives sont structurées en deux parties : 

Une partie d’initialisation, également appelée ancre (anchor) : C’est la requête initiale, définie à l’aide du mot-clé RECURSIVE et de la CTE. 

Une partie récursive : C’est la requête itérative qui réutilise la CTE et s’appuie sur un UNION ALL pour concaténer les résultats. 

– Cas d’usage : Extraction du data lineage 

L’objectif attendu est d’obtenir une table contenant l’ensemble du data lineage d’une table choisie, avec en ligne toutes les dépendances entre colonnes sources et colonnes cibles intervenant dans sa construction. 

Pour visualiser la profondeur de la dépendance, une colonne level est ajoutée, contenant des valeurs numériques : 

Une valeur de 1 indique qu’il faut remonter une table en amont de la table finale. Une valeur de 2 signifie qu’il faut remonter deux niveaux, et ainsi de suite. 

Essayons maintenant d’extraire l’ensemble des dernières dépendances pour une table donnée, et ce pour tous ses champs à l’aide des CTEs récursives. 

Une fois ces étapes réalisées, il s’agit maintenant de construire l’ancre (anchor) de la CTE récursive. 

Construction de l’ancre 

Rien de particulièrement complexe ici, si ce n’est l’application de trois filtres essentiels : Sur la table choisie (cible de l’analyse). 

Sur la dernière version de la table (grâce au timestamp le plus récent du lineage). 

Sur la liste des colonnes (utilisée ensuite dans la phase récursive pour effectuer la jointure). 

Et l’initialisation de la colonne level. 

Construction de la partie récursive 

Pour construire la partie récursive de la CTE, deux jointures internes (INNER JOIN) sont nécessaires : 

Sur lineage_cte : pour relier chaque colonne cible à sa colonne source précédente, et ainsi reconstruire la chaîne de transformation des données. 

Sur recent : pour filtrer les relations et ne conserver que les plus récentes par colonne et table cible, assurant ainsi un lineage à jour. 

À chaque itération, la valeur du champ level est incrémentée pour refléter la profondeur de la dépendance. 

La requête dans sa version finale : 

Deux paramètres sont proposés : 

MAX RECURSION LEVEL : Ce paramètre par défaut à 100, limite la profondeur de récursion générant une erreur « RECURSION_LEVEL_LIMIT_EXCEEDED » si celui-ci est dépassé : Lien 

WITH RECURSIVE recursive_cte(n) MAX RECURSION LEVEL 200 AS ( …) 

La taille du jeu de données retourné en résultat ne peut excéder la limite par défaut de 1 million de lignes, si celle-ci est dépassée, l’erreur suivante est levée RECURSION_ROW_LIMIT_EXCEEDED : Lien 

Conclusion 

Arrivés à l’issue de cet article, nous espérons avoir démontré l’utilité des CTEs récursives à travers un cas concret : l’extraction du data lineage d’une table. 

Au-delà de la mise à disposition d’un outil technique, notre objectif était également de souligner l’importance du data lineage dans Unity Catalog, et de vous permettre d’explorer les différentes fonctionnalités nativement intégrées. 

Par ailleurs, l’arrivée de Spark 4.0 et des nouvelles fonctionnalités SQL qu’il supporte marque une avancée significative vers la création d’une data platform unifiée. Nous vous encourageons vivement à découvrir les autres nouveautés, qui pourraient s’avérer précieuses dans vos projets data. 

L’article Spark supporte désormais les CTEs recursives est apparu en premier sur Le blog de Cellenza.

Dans Azure, les services de messagerie sont conçus pour répondre à des besoins variés, allant de la gestion de flux de données massifs à la coordination de workflows complexes. Un message peut être une commande (ordre d’agir) ou un événement (notification). Microsoft Azure propose plusieurs services de messagerie adaptés à différents scénarios d’architecture moderne. 

Quel service choisir ? Matrice de décision pratique 

1. Azure Service Bus : l’épine dorsale de vos architectures CQRS 

Azure Service Bus est un service de messagerie d’entreprise entièrement géré, parfait pour implémenter des patterns comme CQRS ou Saga. Lors de mes labs AZ-204, j’ai réalisé à quel point sa fiabilité était cruciale pour les commandes critiques. Il prend en charge les protocoles AMQP 1.0 et HTTP/REST, et propose deux principaux modèles de communication : les files d’attente (point-à-point) et les rubriques/abonnements (publication/abonnement). 

Exemple de code – Pattern CQRS avec Service Bus 

2. Azure Event Hubs : la fondation de l’Event Sourcing 

En découvrant Event Hubs durant ma préparation, j’ai compris pourquoi il est la référence pour l’Event Sourcing. Compatible avec Apache Kafka, il excelle pour persister des millions d’événements par seconde en temps réel, créant un store d’événements immuable. 

Exemple de code – Event Sourcing avec Event Hubs 

3. Azure Event Grid : l’orchestrateur de la Choreography 

Event Grid m’a fasciné par sa capacité à implémenter élégamment le pattern Choreography. Contrairement à l’orchestration centralisée, chaque service réagit de manière autonome aux événements, créant une architecture résiliente et découplée. 

Exemple de code – Pattern Choreography avec Event Grid 

4. Azure Storage Queues : le champion du Queue-Based Load Leveling 

Storage Queues pourrait sembler basique, mais il brille dans l’implémentation du pattern Queue-Based Load Leveling. Lors de mes exercices pratiques, j’ai découvert sa puissance pour lisser les pics de charge à coût minimal. 

Exemple de code – Load Leveling avec Storage Queues 

Architecture hybride : la synergie des patterns 

Dans la réalité des projets d’entreprises, ces services fonctionnent ensemble. Voici l’architecture que j’ai implémentée lors d’un projet post-certification, combinant plusieurs patterns : 

Pièges courants et solutions apprises sur le terrain 

Service Bus : Gestion proactive des Dead Letters 

Event Hubs : Checkpoint économiquement optimisé 

 Conclusion : architecture messaging moderne 

Ma découverte de ces services lors de la préparation AZ-204 m’a révélé qu’Azure offre bien plus qu’une simple palette d’outils. C’est un écosystème cohérent pour implémenter les patterns architecturaux modernes : 

• Service Bus : Excellence pour CQRS et les transactions critiques 

• Event Hubs : Fondation robuste pour l’Event Sourcing et l’analytics 

• Event Grid : Simplicité serverless pour la Choreography 

• Storage Queues : Efficacité économique pour le Load Leveling 

Points clés de mon retour d’expérience 

1. Commencez par le pattern, puis choisissez le service 
2. Combinez intelligemment : une approche hybride peut réduire les coûts de 85% 
3. Appliquez le Well-Architected Framework dès le début 
4. Anticipez les patterns d’échec : dead letters, checkpoints et poison messages 

Ressources pour approfondir 

• Event Sourcing Pattern : Maîtrisez l’append-only store 

• Choreography Pattern : Découplage intelligent des microservices 

• Queue-Based Load Leveling : Lissage de charge maîtrisé 

• Service Bus Best Practices : Excellence opérationnelle garantie 

L’article Implémentation de la communication basée sur les messages dans l’écosystème Azure : mon retour d’expérience AZ-204 est apparu en premier sur Le blog de Cellenza.

C’est dans ce contexte que Azure Integration Services (AIS) s’impose comme une alternative moderne, cloud-native. Mais migrer de BizTalk vers AIS ne se résume pas à un simple lift-and-shift. Il s’agit d’un véritable changement de paradigme. Cet article a pour objectif de mettre en lumière les correspondances techniques entre BizTalk et les composants Azure, afin de vous aider à mieux appréhender cette transition. Nous verrons comment les orchestrations, adaptateurs, mappings, pipelines ou encore la gestion des erreurs trouvent leurs équivalents ou évolutions dans l’écosystème Azure. 

En préambule avant de plonger dans les correspondances entre les fonctionnalités de BizTalk et les services Azure, nous allons voir quelles sont les plus-values des plateformes d’intégration Azure. 

Les plus-values des plateformes d’intégration Azure 

Migrer sa plateforme d’intégration BizTalk vers Azure amène un certain nombre d’avantage qui sont :  

• Une plateforme managée et hautement scalable
  Azure Integration Services repose sur des services entièrement managés, libérant les équipes des contraintes liées à l’infrastructure. La plateforme s’adapte automatiquement aux charges de travail, permettant une mise à l’échelle horizontale et verticale selon les besoins, tout en garantissant une haute disponibilité et une résilience native. 

• Une sécurité native et complète
  Azure offre une sécurité intégrée de bout en bout, avec une authentification centralisée via Azure EntraID, le chiffrement automatique des données en transit et au repos, ainsi qu’une gestion fine des accès et des identités (RBAC, Managed Identities).  

• Une architecture modulaire et sur-mesure
  Grâce à une approche basée sur des services découplés (Logic Apps, API Management, Service Bus…), la solution s’ajuste aux cas d’usage spécifiques de chaque organisation. Elle permet de composer une plateforme d’intégration sur-mesure, évolutive dans le temps. 

• Une interopérabilité étendue et moderne
  Azure prend en charge une large variété de protocoles et de formats d’échange, comme REST, JSON, EDIFACT, …. Cela permet une intégration fluide avec les systèmes existants, qu’ils soient on-premise ou dans le cloud. Azure permet également d’adopter de nouveaux patterns modernes comme l’event-driven et le streaming. 

• Un socle technologique robuste basé sur les services Azure mainstream
  La plateforme s’appuie sur des composants largement utilisés de l’écosystème Azure, tels que Key Vault (gestion des secrets), Storage Account (stockage cloud), ou Log Analytics Workspace et App Insight (pour la centralisation et l’exploitation des logs). 

Après avoir examiné les plus-values d’une migration vers Azure, il est désormais pertinent d’analyser les correspondances entre BizTalk Server et Azure. Bien identifier ces équivalences, tout en comprenant les différences induites par le changement de paradigme, est essentiel pour se projeter sereinement dans ce chantier de transformation. Cela permet également de poser les bases d’une stratégie de migration claire et structurée. 

Migration BizTalk : quels composants Azure pour remplacer quoi ? 

À la différence de BizTalk, qui est une solution EAI (Enterprise Application Integration) packagée, où toutes les fonctionnalités sont regroupées dans un outil unique, Azure propose un ensemble de services modulaires à assembler selon les besoins pour construire sa propre plateforme d’intégration. Ce changement peut être déroutant pour les équipes habituées à une approche monolithique. 

C’est pour répondre à cette complexité que Microsoft a regroupé plusieurs de ses services d’intégration sous la suite Azure Integration Services (AIS), afin de clarifier l’offre et de faciliter la mise en œuvre de solutions d’intégration cloud modernes. 

Azure Integration Services (AIS) est une boîte à outils complète contenant tout le nécessaire pour concevoir des interfaces d’intégration. Elle se compose de six services clés :
Logic Apps, Azure Functions, API Management, Service Bus, Event Grid et Azure Data Factory. Pour une description détaillée de chacun de ces services et de leurs cas d’usage, vous pouvez consulter notre article de blog : Comment décliner sa plateforme d’intégration en services Azure avec AIS ? 

Pour répondre aux enjeux de sécurité, de supervision et de connectivité réseau, AIS est complété par d’autres services Azure mainstream tels que : 

• Azure Key Vault pour la gestion des secrets, 

• Azure Storage Account pour le stockage de fichiers et messages, 

• et des composants réseau comme Azure Virtual Network (VNet). 

Nous allons maintenant passer en revue les principales fonctionnalités de BizTalk Server et présenter leurs équivalents dans l’univers Azure, afin de vous aider à mieux comprendre les correspondances et les adaptations nécessaires pour réussir votre migration. 

 Orchestration 

Le principal atout de BizTalk est la particularité d’enchainer des actions de manière séquentielle. Ce composant est l’“Orchestration”, fonctionnalité majeure dans la création et l’ordonnancement des flux…  

Côté Azure, c’est le composant LogicApp qui remplit ce rôle.  

Ces actions séquentielles peuvent se faire de manière synchrone, c’est-à-dire que le flux se déroule “en temps réel”, coordonnées.  

Bien entendu la possibilité de développer des flux asynchrones est présente. Dans cette situation, le comportement naturel de BizTalk permet de persister et sauvegarder les messages dans la “MessageBox”. Il permet grâce aux orchestrations de pouvoir retourner un message après un certain délai. Dans ce cas, il est possible d’envoyer un appel au partenaire source après avoir reçu la réponse du partenaire destination.  

Dans le cas des LogicApps, il est possible de sauvegarder/persister un message grâce au ServiceBus dans le but de le consommer plus tard en le stockant temporairement dans une queue par exemple (utilisation du pattern publish/subscribe). 

Connecteurs-adapteurs et ports 

Contrairement à BizTalk, LogicApp concentre à la fois la notion d’orchestrations mais aussi celle de port (send ou receive). Là où BizTalk possède plusieurs éléments à configurer pour qu’un flux soit pleinement fonctionnel, Azure LogicApp permet de centraliser l’ensemble des composants. 

Par conséquent, le développement peut être plus rapide et les erreurs moins difficiles à monitorer. 

En détail : 

La notion de connecteur dans LogicApp, correspond à la configuration des Send et/ou Receive Port dans BizTalk. Ces artefacts permettent de choisir les connecteurs à utiliser en fonction des besoins.  

Il est à noter que dans BizTalk, il y a un nombre très restreint de choix en comparaison avec Azure. On se limite à une dizaine de connecteurs fournis par Microsoft. Néanmoins, nous faisons parfois face à des situations qui demandent l’utilisation de connecteurs spéciaux développés par des éditeurs tiers permettant la communication avec certains applicatifs. Et qui dit éditeurs, dit, bien entendu, coût supplémentaire… Nous pouvons aussi noter que la maintenabilité n’est pas garantie ne serait-ce qu’avec d’anciennes versions ou bien les dernières en date. 

Dans LogicApp Azure les connecteurs sont nombreux et maintenus ; c’est une très grande force de ce composant 

1.Les connecteurs dit “Managed” 

Les connecteurs “Managed” s’exécutent dans des clusters de connecteurs partagés dans le cloud Azure mutualisés. Ils sont accessibles via appel HTTP.  Ces connecteurs possèdent souvent des fonctionnalités supplémentaires et avancés mais sont facturés à l’utilisation.  

2. Les connecteurs dit “Built-In” 

Les connecteurs “Built-In” s’exécutent dans le même cluster et runtime que la Logic App Standard car ils sont préinstallés dans l’environnement. Ces connecteurs ont la possibilité de se connecter à des VNETs et sont tenu à jour par Microsoft. Et dernier détail important, ils n’entrainent pas de surcoût. 

3.Les connecteurs dit “Custom” 

Azure vous donne la possibilité de créer vos propres connecteurs. On les appelle les connecteurs “custom”. Les paramétrages se font via le composant “Logic App Custom Connector”. Une fois créé il est utilisable par l’ensemble des LogicApp du même tenant. Et, de surcroit, il peut être partagé à plusieurs utilisateurs ou groupes Entra ID. Et bien sûr il est possible de gérer le versionning du composant. 

Attention toutefois, les connecteur Managed et Custom engendre des coûts supplémentaires à l’utilisation.  

Mapping 

Enjeu important dans la communication entre applicatif la transformation des messages. 

Dans LogicApp il est possible d’utiliser un « DataMapper », qui est un héritage du DataMapper BizTalk. 

Nous avons donc 2 composants relativement identiques pour nos 2 applicatifs à ceci près que concernant le data mapper de LogicApp, celui-ci est compatible avec le XSLT 3.0. Or BizTalk, lui, ne supporte que le 1.0. 

Chose importante à prendre en compte, Azure LogicApp Standard et BizTalk utilise le même mécanisme de mapping. Les maps sont développées via le XSLT et les schémas sont au format XSD. Cela assure une compatibilité entre les deux. 

Par conséquent, un “lift & shift” des maps XSLT et des schéma XSD depuis BizTalk est très rapide. Pas besoin de redéveloppement. 

Un point a noté tout de même, ce lift & shift avec l’utilisation LogicApp Consumption nécessite l’utilisation du service Integration Account qui peut s’avérer onéreux. 

 APIs  

Il est bien entendu possible d’utiliser des APIs et de permettre aux différents partenaires de les utiliser.  

Au sein de BizTalk, il est nécessaire d’utiliser IIS (le serveur web Microsoft). Il faut configurer l’API et se synchroniser avec les équipes infrastructures et/ou réseaux pour permettre aux partenaires de pouvoir les utiliser (credentials, whitelisting, etc.). 

Au contraire, dans Azure on peut utiliser API Management avec tous les avantages que ça procure. La facilité de pouvoir déployer rapidement une API par exemple. Il est tout aussi complet en termes de configuration réseau et de règles firewall ou load balancing. En résumé plus simple et mieux intégré. 

Le rôle de Backend peut être endossé par une LogicApp comme mentionner ci-dessus, mais il est tout à fait envisageable de créer des Azure Function pour remplir ce rôle. 

« Helpers » C# 

Il est possible que les actions disponibles dans une LogicApp ne permettent pas de résoudre une problématique donnée.  

Pour y répondre, il est possible de développer un “module” encapsulant du code (dans le cas de BizTalk, uniquement en C#). 

Dans cette situation, dans un environnement BizTalk on utilisera Visual Studio et le framework .Net. 

Il existe deux possibilités pour exécuter du code dans une Logic App : 

1. Le “Inline C#” : permet d’intégrer du code directement dans la Logic App, idéal pour des traitements simples et ponctuels, sans nécessiter de déploiement externe. 

1. Les Azure Functions : permettent d’exécuter des traitements plus complexes. Deux approches sont possibles : 

• Azure Function Embedded : la fonction s’exécute dans le même runtime que la Logic App Standard à laquelle elle est rattachée. Aucun appel réseau n’est nécessaire, ce qui réduit la latence. Ce mode est recommandé lorsque le traitement est spécifique à une seule Logic App. Il permet également de mutualiser le pipeline CI/CD avec celui de la Logic App, simplifiant le déploiement. 

• Azure Function Externe : il s’agit d’un composant propre de la plateforme, avec son runtime, sa configuration et son cycle CI/CD. Cette approche est pertinente lorsque la fonction est partagée entre plusieurs composants (Logic Apps, APIs, etc.). Elle favorise la réutilisabilité du code et une meilleure séparation des responsabilités. 

Durable messaging/persistence 

Les messages peuvent être durablement sauvegarder dans la “MessageBox” BizTalk pour les traiter à nouveaux en cas d’erreur. Il est possible de configurer les orchestrations en “long running” pour ce type de traitement. 

Une possibilité similaire est proposée avec LogicApp en utilisant la configuration Stateful. 

Là ou un une LogicApp en mode Stateless doit avoir une durée maximum de 5 minutes, une LogicApp en mode Stateful est limité à 90 jours ! 

Il existe un autre composant intervenant dans la persistance de données : le ServiceBus. Celui-ci est l’un des éléments centraux pour mettre en place le pattern publish-subscribe. C’est un message broker, un intermédiaire entre différents composants. Il permet la réception/stockage de messages dans une queue ou un topic. Ils sont sauvegardés suivant le paramètre TTL (Time To Live). A noter que pour le Basic Tier il est de 14 jours. Dans le cas du premium tier, le TTL est paramétrable. 

 Monitoring 

Azure bénéficie du service de AppInsight permettant de développer son propre monitoring des flux. Il existe aussi l’outil Log Analytics qui permet de connecter les logs qui prend leur source depuis différents composants. L’atout de Log Analytics est le langage de requête (KQL) qui facilite l’exploitation des données stockées. 

Concernant BizTalk plusieurs alternatives peuvent être envisagé. L’exploitation des données stocker dans le BAM par une application tierce (a développé en interne ou grâce à un produit du marché) ou alors l’utilisation seul de la Console d’Administration BizTalk qui, quant à elle, n’est à usage strictement technique. 

Le BHM ou BizTalk Health Monitor peut s’apparenté au composant HealthCheck utilisable par plusieurs composant AIS. Il donne des métriques de « bonne santé » de la plateforme. Il s’agit d’un monitoring orienté technique. 

Routing/Special rules 

Avec le BRE (Business Rules Engine) il est possible d’appliquer des règles particulières. Il permet de découpler la logique métier à la logique technique. 

En ce qui concerne Azure un composant en « Preview » est disponible, le Azure Logic Apps Rules Engine 

Security 

Du fait des différences structurelles entre un environnement on-premise et le cloud, le volet sécurité ne peut pas être abordé de la même manière dans BizTalk et Azure. 

Dans BizTalk, la sécurité repose généralement sur le Single Sign-On (SSO), qui centralise la gestion des connexions entre les différentes briques de la solution. 

En revanche, dans Azure, chaque composant doit gérer son accès de manière autonome. Pour cela, la plateforme s’appuie sur deux mécanismes clés : 

• Managed Identity, qui permet à un service Azure de s’authentifier auprès d’un autre sans stocker de secrets, 

• RBAC (Role-Based Access Control), qui permet de définir précisément les droits d’accès à chaque ressource. 

Le stockage des informations sensibles (mots de passe, clés, chaînes de connexion, etc.) s’effectue via le service Azure Key Vault qui est dédié à la gestion des secrets, des certificats et des clés de chiffrement. 

Pour conclure ce comparatif entre les fonctionnalités de BizTalk et celles d’Azure, voici un résumé graphique réalisé par Harold Campos, Principal Product Manager – Azure Logic Apps chez Microsoft, qui permet de visualiser clairement les équivalences entre les deux environnements : 

Lien : https://www.linkedin.com/feed/update/urn:li:activity:7271841022974783488/

Cet article, met en lumière les équivalences entre BizTalk Server et les composants Azure, montrant que la majorité des concepts clés de l’intégration (orchestrations, adaptateurs, mapping, pipelines, etc.) trouvent leur place – parfois repensée, souvent enrichie – dans l’écosystème Azure : LogicApp, ServiceBus, APIM. Ce comparatif permet de démystifier la migration vers Azure, de mieux comprendre la transition, d’identifier les points d’attention, et de poser les bases d’une migration structurée. 

Au-delà de cette correspondance technique, migrer vers une plateforme cloud comme AIS ouvre la voie à de nombreux avantages : une infrastructure managée, hautement scalable, sécurisée nativement, et bâtie sur des services Azure mainstream (KeyVault, LogAnalytics, StorageAccount, …). C’est aussi l’opportunité d’adopter des approches modernes (event-driven, microservices, DevOps), mieux alignées avec les besoins d’agilité et d’interopérabilité d’aujourd’hui. 

L’article BizTalk : comment migrer efficacement vers Azure Integration Services ? est apparu en premier sur Le blog de Cellenza.

Notre objectif ? Cumuler un maximum de kilomètres pour faire avancer la recherche contre la SLA, plus connue sous le nom de maladie de Charcot. 

Un défi collectif, connecté et qui a du cœur 

Du 1er au 30 juin, les Cellenzans de toutes les régions se sont mobilisés, à pied, à vélo, en courant ou en nageant. Chaque kilomètre a fait la différence ! Le principe était simple : 1 kilomètre parcouru = 1 € reversé par Cellenza à l’ARSLA. 

Semaine après semaine, les kilomètres se sont additionnés, transformant chaque effort individuel en un formidable élan collectif en faveur de la recherche. 

Un impact concret 

Ce défi sportif s’inscrit dans une démarche solidaire plus large, portée notamment par MicroDON et son dispositif d’arrondi sur salaire, en place chez Cellenza depuis 2023. 

Grâce à ce mécanisme simple et transparent, les collaborateurs peuvent facilement contribuer à un don régulier, prélevé mensuellement directement sur leur salaire. Ce système permet de soutenir durablement et concrètement les différentes actions entreprises par les associations.  

L’esprit OneTeam, plus fort que jamais 

Au-delà des nombreux kilomètres parcourus, ce défi a été une formidable démonstration de l’esprit “OneTeam” qui nous anime, au service d’une cause essentielle. L’énergie, la bonne humeur et l’engagement de chacun ont insufflé une belle dynamique, directement au profit de l’ARSLA. 

Un immense merci et un grand bravo à toutes celles et ceux qui se sont mobilisés avec cœur et enthousiasme. Votre participation a réellement fait la différence dans notre soutien à la recherche contre la SLA !

 Bravo à toutes et à tous pour cette belle mobilisation ! 

L’élan continue ! 

L’engagement ne s’arrête pas là.
La mobilisation autour du mois “Éclats de Juin !” a été un vrai succès, mais le combat contre la SLA continue.
Pour découvrir les missions de l’ARSLA, suivre les avancées de la recherche et soutenir durablement leurs actions, rendez-vous dès maintenant sur leur site officiel :
https://eclatsdejuin.arsla.org/home 

Un grand merci encore à toute la Team Cellenza. À très vite pour de nouveaux défis ! 

L’article Cellenza et l’ARSLA : Ensemble, on a défié la SLA ! est apparu en premier sur Le blog de Cellenza.