Istio et Kueue pour certains, Traefik et Volcano pour d’autres ; parfois Kubeflow, parfois KubeRay, ou les deux… Les fournisseurs de plates-formes Kubernetes ont emprunté divers chemins pour démontrer leur conformité à la « spécification IA » élaborée par la CNCF.

Cette spec définit un ensemble de capacités, d’API et de configurations qu’un cluster certifié « conforme Kubernetes » doit proposer pour exécuter de façon fiable des workloads IA/ML. Principal objectif : éviter une fragmentation qui compromettrait la portabilité.

Un premier tour d’autocertification avec 9 éléments obligatoires

Les travaux avaient officiellement démarré cet été. Une v1 a été publiée depuis et un premier round de certification a été lancé. Plus précisément d’autocertification : le processus est pour le moment déclaratif. Une suite de tests automatisés est censée prendre le relais, mais pas avant 2026.

Beaucoup d’éléments inscrits dans la spécification ne sont, en tout cas pour le moment, pas obligatoires. Parmi eux :

• Assurer que des pilotes compatibles et les configs runtime correspondantes sont correctement installés et maintenus sur les nœuds dotés d’accélérateurs
• Faciliter le tirage de grosses images de conteneurs (par exemple à travers une réplication ou une mise en cache près des nœuds d’exécution)
• Permettre la gestion unifiée de jobs indépendants via un mécanisme gérant les API JobSet
• Autoriser le déploiement de conteneurs confidentiels dans des environnements d’exécution sécurisés (enclaves matérielles)
• Fournir un mécanisme de détection des accélérateurs en erreur, avec éventuellement une remédiation automatisée

9 éléments sont actuellement obligatoires. Dans les grandes lignes :

1. Prendre en charge l’allocation dynamique des ressources (DRA)
2. Gérer la Gateway API de Kubernetes, dans une implémentation permettant une « gestion avancée » pour les services d’inférence (distribution pondérée du trafic, routage sur la base des en-têtes, intégration avec les maillages de services…)
3. Permettre d’installer et d’exploiter au moins une solution de planification des gangs
4. Gérer la mise à l’échelle verticale des groupes de nœuds contenant des types d’accélérateurs spécifiques
5. Si présent, assurer un fonctionnement correct de l’HorizontalPodAutoscaler pour les pods qui exploitent des accélérateurs
6. Exposer, pour les types d’accélérateurs pris en charge, des métriques granulaires, via un endpoint standardisé, et dans un format lisible par la machine (au minimum, taux d’utilisation par accélérateur + occupation mémoire)
7. Découverte et collecte de métriques de workloads dans un format standard
8. Isolation des accès aux accélérateurs depuis les conteneurs
9. Possibilité d’installer et d’exécuter de façon fiable au moins un opérateur IA complexe disposant d’un CRD

Chaque certification vaut pour un an et s’applique à une version spécifique de Kubernetes. En l’état, soit la 1.33 (8 solutions certifiées), soit la 1.34 (11 solutions certifiées).

Les 8 solutions (auto)certifiées sur Kubernetes 1.33

Premier dans l'ordre alphabétique, CoreWeave Kubernetes Services (CKS).
Entre autres commentaires insérés dans sa déclaration de conformité, le "néo-cloud" américain - voir notre article à son sujet - rappelle gérer le planificateur SUNK (Slurm on Kubernetes). Il explique aussi que l'isolation des accès est pour l'instant traitée avec des plug-in, en attendant de passer au DRA lorsque le support fournisseur sera plus mature.

DaoCloud Enterprise n'implémente pas le DRA (il faut dire que les API sont désactivées par défaut sur Kubernetes 1.33, de sorte que la spec n'impose pas la fonctionnalité). Destiné à l'exécution sur site, il ne fournit pas non plus d'autoscaler vertical.

Pour sa plate-forme Gardener, la NeoNephos Foundation (projet de la Fondation Linux Europe) livre une preuve d'implémentation de la Gateway API via Traefik. Et de la planification des gangs via Kueue. L'autoscaling horizontal est géré avec une stack associant Prometheus et DCGM (NVIDIA Datacenter GPU Manager). Comme "opérateur IA complexe", KubeRay a été choisi.

L'entreprise allemande Giant Swarm fournit la plate-forme du même nom. Elle n'a pas ajouté de commentaires à son autocertification. Les renvois vers sa documentation montrent toutefois que Kueue a été sélectionné pour démontrer la conformité sur la partie planification des gangs, et KubeRay en guise d'opérateur IA.

Red Hat est également au rendez-vous, avec la dernière version d'OpenShift (4.20). Lui aussi a opté pour Kueue. Comme opérateur IA, la filiale d'IBM a utilisé Kubeflow Trainer, avec plusieurs CRD (TrainJob, TrainingRuntime, ClusterTrainingRuntime). Elle précise, concernant les métriques d'accélérateurs, propose des opérateurs dédiés pour les GPU AMD en plus des GPU NVIDIA.

SUSE a autocertifié RKE2 (deuxième itération de Rancher Kubernetes Engine). Là aussi sans commentaires supplémentaires, mais avec un renvoi vers une nouvelle section de sa doc consacrée à la conformité vis-à-vis de la spec CNCF. On y découvre que Volcano a été privilégié pour la planification des gangs. Et que pour la collecte de métriques, la solution SUSE AI est mise en avant.

Red Hat a autocertifié un deuxième produit : ROSA (Red Hat OpenShift Service on AWS), dans sa dernière version. Avec, la même base que pour OpenShift, mais des validations spécifiques.

Talos Linux, OS immuable pour Kubernetes, a également été certifié, par son éditeur Sidero Labs. Lequel signale qu'aucun autoscaler vertical spécifique n'est fourni et que le produit n'embarque pas, en standard, d'outils d'observabilité.

Les 11 solutions (auto)certifiées sur Kubernetes 1.34

Premier dans l'ordre alphabétique, ACK (Alibaba Cloud Container Service for Kubernetes). Sa conformité a été démontrée en utilisant à la fois Spark et Ray. Sur la partie métriques, Alibaba a exploité son Prometheus managé.

AKS (Azure Kubernetes Service) a aussi été autocertifié. Microsoft a utilisé Istio, Kueue et DCGM, entre autres. Pour les opérateurs IA, il a fait un choix particulier au-delà de Ray : KAITO (Kubernetes AI Toolchain Operator), projet en sandbox à la CNCF et qui repose sur vLLM.

Baidu a autocertifié sa solution CCE (Cloud Container Engine). Avec Volcano pour l'implémentation Gateway API, du Prometheus managé pour l'autoscaling horizontal... et un déploiement SGLang pour la partie contrôleur IA.

Autocertifié sur Kubernetes 1.33, CKS (CoreWeave Kubernetes Service) l'est aussi sur la version 1.34.

Amazon a essentiellement recouru à ses propres services pour démontrer la conformité d'EKS (Elastic Kubernetes Service). Entre autres, son contrôleur AWS Load Balancer, son planificateur AWS Batch, son outil de supervision CloudWatch et son collecteur de métriques Neuron Monitor.

GKE (Google Kubernetes Engine) est également autocertifié. Comme Amazon, Google met en avant ses propres services... et un tuto, destiné à construire une plate-forme ML associant Ray et Kubeflow.

KKP (Kubermatic Kubernetes Platform) a sa propre stack MLA ("Monitoring Logging & Alerting"), exploitée dans le cadre de son autocertification. Il a aussi son propre contrôleur de passerelle (KubeLB).

Avec LKE (Linode Kubernetes Engine), Akamai a son propre autoscaler vertical. Pour les pods, il passe par l'adaptateur Prometheus. La collecte de métriques relatives aux accélérateurs passe par DCGM. Istio est utilisé comme implémentation référente de la Gateway API.

Istio a aussi été le choix d'Oracle pour démontrer la conformité d'OKE (OCI Kubernetes Engine). On aura noté que pour les métriques de workloads, le groupe américain a son propre projet OCI GPU Scanner, mis à disposition sous licence libre (UPL) et installable soit via Terraform, soit via Helm, soit comme add-on depuis la console OCI.

Autocertifié sur Kubernetes 1.33, Talos Linux l'est aussi sur la version 1.34.

Le dernier dans l'ordre alphabétique est VKS (VMware Kubernetes Service). VMware l'a autocertifié en s'appuyant notamment sur Istio, Kueue, Prometheus, DCGM et KubeRay.

Illustration

The post Kubernetes : les 17 premières plates-formes « certifiées IA » appeared first on Silicon.fr.

Broadcom et VMware, cela fera bientôt deux ans.

Le 22 novembre 2023, le premier finalisait l’acquisition du second. Il n’allait pas tarder à en bouleverser la politique commerciale, avec les conséquences que l’on sait.

Quantité de fournisseurs d’offres concurrentes se sont engouffrés dans la brèche, tentant de capter le replatforming des parcs de VM. Red Hat n’y a pas fait exception. Il a évidemment mis en avant la conteneurisation sur OpenShift. Mais aussi la brique de virtualisation intégrée à la plate-forme depuis l’été 2020. Jusqu’à en faire un produit spécifique, lancé début 2025 : OpenShift Virtualization Engine, qui n’inclut pas de droit d’usage de conteneurs applicatifs.

Topologie localnet et instances personnalisées

Au-delà de la stratégie commerciale, OpenShift Virtualization a connu des évolutions fonctionnelles notables depuis la fusion Broadcom-VMware. Six versions mineures sont sorties, à commencer par la 4.15 (publiée le 27 février 2024 ; arrivée en fin de vie le 27 août 2025).

Cette version avait notamment apporté la gestion du branchement à chaud d’interfaces réseau secondaires sur les VM (hors interfaces SR-IOV). Elle avait aussi ajouté la prise en charge de la topologie localnet pour les réseaux secondaires OVN-Kubernetes (connexion à la sous-couche physique).

Autre élément ajouté : le KSM (kernel samepage merging). Cette fonctionnalité s’enclenche lorsqu’un nœud est surchargé. Elle déduplique les données identiques trouvées dans les pages mémoire des VM.

OpenShift Virtualization 4.15 a également permis d’activer l’accès aux logs console des invités et de configurer des clusters pour les workloads DPDK (Data Plane Development Kit, délégation du traitement des paquets TCP à des processus en espace utilisateur) sur SR-IOV. La console web avait été enrichie en parallèle pour permettre l’installation et l’édition de types d’instances personnalisés. Et pour importer des secrets depuis d’autres projets lors de l’ajout d’une clé SSH publique à une VM en cours de création ou d’un secret à une VM existante.

Hotplug de vCPU et accès headless aux VM

Le 27 juin 2024 sortait OpenShift Virtualization 4.16. Cette version est actuellement en phase de maintenance, jusqu’au 27 décembre 2025. Le support étendu durera jusqu’au 27 juin 2026. Avec elle, le hotplug de vCPU est passé en disponibilité générale.

Il est aussi devenu possible d’accéder à une VM à travers des services Kubernetes headless, en utilisant son nom de domaine interne. Et d’activer la feature gate AutoResourceLimits pour gérer automatiquement les limites CPU et mémoire des VM.

OpenShift Virtualization 4.16 a aussi ajouté la possibilité de sélectionner les options sysprep à la création de VM Windows plutôt que par après. Et d’exposer certaines métriques d’hôte ou d’invité au sein des VM, en ligne de commande ou via l’outil vm-dump-metrics.

Gestion de la densité des workloads et exposition de périphériques USB

OpenShift Virtualization 4.17, sorti le 1^er octobre 2024, arrivera en fin de vie le 1^er avril 2026, sans phase de support étendu.

Avec cette version, Red Hat a certifié la prise en charge de Windows Server 2025 comme OS invité. Il a aussi permis de sélectionner un namespace personnalisé pour ses golden images. Et donné la possibilité d’accroître la densité de workloads dans les VM en surréservant (overcommit) la RAM. Comme d’exposer des périphériques USB dans un cluster, de sorte que les propriétaires de VM peuvent ensuite les assigner.

Le hotplug de CPU et de mémoire depuis la console est passé en disponibilité générale avec OpenShift Virtualization 4.17. Même chose pour la configuration de stratégies d’éviction de VM à l’échelle d’un cluster.

Réseaux définis par l’utilisateur et changement à chaud de type d’instance

Sorti le 25 février 2025, OpenShift Virtualization 4.18 arrivera en fin de maintenance le 25 août 2026. Le support étendu durera jusqu’au 25 février 2027.

Depuis cette version, on peut connecter une VM à un réseau défini par l’utilisateur sur l’interface primaire. On peut aussi changer le type d’instance associé à une VM en cours d’exécution, sans redémarrage.

Autre ajout : la capacité de créer des snapshots de VM auxquelles on ajoute un vTPM. Et de les restaurer à partir de ces snapshots (mais pas d’en créer de nouvelles, ni de les cloner).

La console a quant à elle évolué pour permettre de contrôler simultanément l’état de plusieurs VM. Et de visualiser des métriques de niveau workload pour les ressources disque, CPU et réseau allouées.

Protection des VM et threads I/O multiples pour le stockage flash

OpenShift Virtualization 4.19 fut publié le 17 juin 2025. Il entrera en phase de maintenance le 17 décembre 2025 et n’aura pas de support étendu.

Avec cette version, RHEL 10 rejoint la liste des OS invités certifiés. Red Hat introduit aussi un mécanisme de protection des VM contre la suppression. Et permet de mettre à jour le type de machine pour plusieurs VM à la fois depuis le CLI OpenShift.

La topologie localnet sur OVN-Kubernetes est devenue utilisable pour connecter une VM à un réseau secondaire défini par l’utilisateur. Et il est devenu possible de configurer un manifeste NodeNetworkConfigurationPolicy pour activer l’écoute LLDP sur tous les ports Ethernet d’un cluster.

Autre nouveauté : la possibilité de configurer plusieurs threads I/O pour les VM utilisant de la mémoire flash. Quant à la console, elle a évolué pour proposer davantage d’actions groupées sur les VM (gestion des étiquettes, déplacement dans un autre dossier au sein d’un même namespace…). Des métriques supplémentaires ont par ailleurs été mises à disposition, concernant les migrations, les vNIC et le stockage alloué aux VM.

Topologie NUMA et saut de versions de correction

La dernière version mineure en date (4.20) est sortie le 21 octobre 2025. Elle arrivera en fin de vie le 21 avril 2027, sans support étendu.

Avec elle, Red Hat permet de sauter des versions de correction (pas besoin d’installer toutes les versions intermédiaires lorsqu’on met à jour).

Plusieurs éléments passent en disponibilité générale, dont la possibilité d’exploiter la topologie NUMA (non-uniform memory access) pour les VM. Elle permet de définir des zones au sein desquelles les CPU bénéficient d’un accès plus rapide aux ressources locales que les CPU externes.

Le profil KubeVirtRelieveAndMigrate, qui améliore la stabilité de l’éviction de VM lors des migrations à chaud, est également passé en disponibilité générale. Idem pour la possibilité de déployer OpenShift Virtualization sur OCI et en bare metal sur cluster ARM64.

Dans la console, on peut désormais, lors de migrations à chaud, spécifier le nœud vers lequel déplacer une VM. Parallèlement, la procédure de hotplug de disques s’est enrichie d’une étape optionnelle permettant de sélectionner un type de bus.

Illustration © Annika – Adobe Stock

The post Comment la virtualisation sur OpenShift a évolué depuis la fusion Broadcom-VMware appeared first on Silicon.fr.

Pour une entreprise, les données représentent la base de son activité, la confiance de ses clients, ainsi que la souveraineté numérique de son pays. Or, ces mêmes données peuvent échapper à son contrôle, non pas à cause d’une violation ou d’une erreur humaine, mais simplement parce que l’entreprise a accepté les conditions générales d’un fournisseur de cloud plusieurs années auparavant. Bien qu’elle puisse accéder à ses données et les utiliser, elle n’a désormais plus aucun contrôle sur l’écosystème qui les entoure, ni sur leur évolution et leurs changements.

Loin d’être une simple hypothèse, ce cas de figure est une réalité quotidienne pour des milliers d’entreprises partout en Europe et dans d’autres pays. Cette situation soulève alors une question cruciale : comment garantir aux entreprises la maîtrise de leurs données et la liberté de choix dans un tel contexte ?

La promesse du multicloud : entre attentes et réalité

Face à ce constat, les entreprises, notamment les PME, se sont tournées vers le multicloud. En effet, travailler avec plusieurs fournisseurs permet de gagner en flexibilité, sécurité et portabilité des workloads. L’idée consiste donc à migrer les applications existantes puis à les optimiser pour le cloud.

Or, dans la pratique, cette promesse n’est pas souvent tenue. Les entreprises sont confrontées à la nécessité de « transférer » leurs applications monolithes sur site vers le cloud, tout en composant avec de nouvelles applications cloud-first créées par une toute nouvelle génération d’ingénieurs et des silos de données fédérés et distribués.

Au cœur du problème se trouve également quelque chose de plus fondamental qu’une simple part de marché : il s’agit de l’érosion de la liberté de choix et, par conséquent, de l’érosion de la souveraineté. Cette dépendance croissante vis-à-vis des plateformes externes nuit à l’innovation.

En parallèle, les DSI sont chargés de vérifier le respect de la conformité pour les écosystèmes tiers, ce qui enferme les autorités chargées de la réglementation dans des interfaces propriétaires. L’avenir du numérique se confond alors étrangement avec le passé et se retrouve monopolisé par une poignée de personnes à la logique interne obscure et aux motivations incompatibles avec celles de la société.

Sécurité nationale, innovation et éthique : des enjeux globaux

Cette dépendance vis-à-vis de quelques fournisseurs soulève alors trois grand enjeux.

C’est d’abord une question de sécurité nationale. Les pays européens prennent conscience que dépendre d’hyperscalers étrangers pour entraîner et déployer leurs modèles d’IA représente un risque pour leur souveraineté. Plusieurs questions se posent alors : que se passerait-il en cas de changements géopolitiques ? Que se passerait-il si l’accès d’un gouvernement aux données de ses propres citoyens est restreint en raison d’obligations légales étrangères ?

C’est aussi une question d’innovation. En effet, les start-ups ne peuvent pas se permettre de payer des frais de sortie qui pénalisent l’exploration et les universités ne devraient pas avoir à adapter leurs recherches aux contraintes commerciales d’un seul fournisseur. Si l’IA est l’équivalent du « moteur à vapeur » du XXIe siècle, il est essentiel de veiller à ce que son carburant, à savoir les données et la puissance de calcul, reste à la fois accessible et portable.

Enfin, c’est une question d’éthique. L’une des plus grandes erreurs dans la gouvernance de l’IA est l’idée que l’éthique peut être superposée à des systèmes fermés. Que les biais des modèles, l’équité algorithmique et l’explicabilité peuvent être réglementés, tout en déployant les modèles les plus sensibles via des API tierces exécutées dans des environnements « Black Box ».

La véritable gouvernance de l’IA commence par la gouvernance des infrastructures. Cela signifie qu’il faut savoir où les modèles sont hébergés, qu’il faut enregistrer et auditer chaque inférence, mais aussi s’assurer que les modèles ne franchissent pas les frontières et ne transgressent pas les règles locales en matière de résidence des données. Or, le fait d’être lié à un seul fournisseur ou de dépendre de services managés purs qui fonctionnent comme des boîtes noires rend tout cela possible.

Vers un cloud souverain et portable

La prochaine évolution technologique est une plateforme qui ne se contente pas de promettre la portabilité, mais qui la met en œuvre. Là où les moteurs de calcul suivent les données et pas l’inverse. Et surtout, là où l’IA peut être exécutée de manière privée, sécurisée et en toute simplicité. Il n’est pas question d’abandonner le cloud, loin de là. Sa flexibilité, son évolutivité et son potentiel de démocratisation sont révolutionnaires. Mais les révolutions doivent être encadrées et le cloud doit avant tout être un choix.

Aujourd’hui, les entreprises sont confrontées à un choix difficile : continuer à dépendre des fournisseurs, accepter l’augmentation des coûts et la réduction de l’autonomie qui en découle, ou basculer vers un environnement où l’infrastructure est fluide, où l’IA peut être souveraine et où le cloud est une capacité qui leur appartient.

Les DSI, les CTO et les CDO doivent être les garants du contrôle absolu des données au sein de l’entreprise, tant du point de vue budgétaire que de celui de la conformité. Une chose est sûre : le droit de traiter les données doit rester entre les mains des personnes qui sont propriétaires de ces données.

*Sergio Gago est Chief Technology Officer chez Cloudera

The post { Tribune Expert } – Cloud computing : un choix technologique devenu un choix d’avenir appeared first on Silicon.fr.

iCloud Mail reste la messagerie intégrée la plus utilisée dans l’écosystème Apple, appréciée pour sa synchronisation native. Les fonctionnalités liées à la gestion d’alias, à ...

Lire plus

Gérer ses photos, documents et sauvegardes devient vite complexe avec plusieurs appareils Apple. iCloud propose une synchronisation automatique et un espace de stockage centralisé pour ...

Lire plus

Un robot iLife A11 désactivé à distance après blocage de la télémétrie. Analyse des risques IoT, fuites passées et défenses réseau locales....

Microsoft promet une nouvelle ère pour les Devs :  .NET 10 booste tout, du code natif à l’IA embarquée. Plus rapide, plus compact et plus malin, il fait tomber les barrières entre cloud, edge et desktop et facilite l’orchestration des agents IA tout en préparant la sécurité des apps à l’ère post-quantique. Depuis plus de […]

L’article .NET 10 : l’IA native propulse la plateforme vers un nouvel âge est apparu en premier sur InformatiqueNews.fr.

Avec IronWood, Google Cloud signe une rupture technologique et stratégique dans l’architecture des accélérateurs IA. Conçu pour l’inférence à très grande échelle, ce TPU de septième génération conjugue puissance de calcul, efficience énergétique et intégration logicielle au sein de l’AI Hypercomputer. Une avancée qui redéfinit les performances du cloud d’inférence et met une forte pression […]

L’article Google officialise la disponibilité sur son cloud de son TPU IronWood, maître de l’inférence à large échelle est apparu en premier sur InformatiqueNews.fr.

— Permalink

— Permalink

« Bleu et S3NS existent grâce à la circulaire ‘cloud au centre’. […] EDF ne fait que déployer la stratégie de l’État voulue par les ministres de l’époque.« 

Alain Garnier, patron de Jamespot, exprime un certain fatalisme quant à la décision du groupe industriel de recourir à ces deux fournisseurs dans la perspective de compléter son cloud privé.

Yann Lechelle, ancien DG de Scaleway, lui fait écho. Il voit, en Bleu et S3NS, des joint-ventures « coercitives » au bénéfice du modèle « cloud de confiance » annoncé en 2021 par Bruno Le Maire. « Le montage répond au cahier des charges qui n’apporte qu’une réponse (très) partielle à notre situation« , ajoute l’intéressé. Non sans affirmer que si la souveraineté de la donnée est garantie (en supposant que la qualification SecNumCloud soit atteinte), la souveraineté technologique ne l’est pas.

SecNumCloud ne résout pas tout…

On retrouve ce discours chez Alain Issarni. « Comment parler de souveraineté quand la technologie sous-jacente reste à ce point contrôlée par les GAFAM ? » se demande l’ancien patron de NumSpot. EDF est, estime-t-il, dans la lignée de l’État français, « qui, sur le Health Data Hub, a refusé pendant 5  ans toute sortie d’Azure« . Il redoute que le groupe tombe dans « le même piège » que l’US Navy, qui a récemment admis qu’il lui faudrait 3 ans pour sortir du cloud de Microsoft, faute de réversibilité réelle.

Une qualification SecNumCloud ne suffit pas à effacer les dépendances structurelles, clame Alain Issarni : que se passe-t-il si Google ou Microsoft décide de couper les mises à jour ? Et comment assurer la souveraineté des « escortes numériques » (accès niveau 3), alors même que le département de la Défense des États-Unis a condamné ce modèle, jugeant Microsoft incapable d’en assurer le contrôle ?

… notamment l’exposition au FISA

« Le plan que j’imaginais se met en place« , commente Tariq Krim. Le fondateur de Netvibes et ancien vice-président du Conseil national du numérique fait référence à un billet qu’il avait publié en juin 2025 : « Comment l’État a confisqué le marché de la souveraineté numérique ».

Dns ce billet, Tariq Krim postule qu’à la fin du premier mandat d’Emmanuel Macron, trois crises (« Covid, polarisation Trump I et émotion autour de l’hébergement du HDH chez Microsoft ») ont servi de prétexte à l’État pour reprendre la main sur la « souveraineté » en écartant les acteurs historiques.
Un glissement sémantique de « souveraineté numérique » à « cloud de confiance » a neutralisé la dimension géopolitique. Trois pôles ont alors façonné la doctrine actuelle, « chacun selon son intérêt » :

• La DGE et l’ANSSI ont élaboré SecNumCloud, qui a verrouillé l’accès au marché
• Bercy a suivi les recommandations des grands groupes, qui réclamaient un Office 365 souverain
• La présidence de la République souhaite continuer à soutenir une start-up nation très dépendante des GAFAM

Le « cloud de confiance », tel que promu par l’État, ne protège pas du FISA (Foreign Intelligence Surveillance Act), déclare Tariq Krim. Il rappelle la récente extension de la portée de cette loi américaine, qui englobe désormais la surveillance des infrastructures en plus de tout logiciel connecté à un réseau, y compris lorsqu’il est déployé sur site. Lors d’une audition au Sénat, l’ANSSI a expliqué disposer d’une solution pour garantir une immunité, mais elle n’en a pas fait de démo publique.

Michel-Marie Maudet fait remarquer qu’EDF lui-même met des guillemets autour de « cloud de confiance ». « Ce n’est pas anodin« , affirme le directeur général de LINAGORA. Il regrette à la fois, un « message désastreux envoyé au marché » et une « erreur stratégique majeure » pour le CSF « Logiciels et solutions numériques de confiance ».

Illustration générée par IA

The post EDF choisit Bleu et S3NS : une vision du cloud de confiance qui interpelle appeared first on Silicon.fr.

Google Cloud a annoncé aujourd’hui une nouvelle génération de technologies de calcul destinées à soutenir la montée en puissance de l’intelligence artificielle, avec notamment le TPU de 7ᵉ génération « Ironwood », de nouvelles machines virtuelles Axion basées sur Arm, et des améliorations logicielles dans son écosystème cloud. L’objectif : fournir une infrastructure complète pour une nouvelle phase de […]

L’article Google Cloud dévoile Ironwood, le TPU le plus puissant jamais conçu est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.

💾

Le rachat de Wiz par Google (pour 32 milliards de dollars) franchit une nouvelle étape importante. Ce deal ne devrait néanmoins être bouclé que l’année prochaine.

En France, environ 70 % des PME seraient équipées d’un CRM, avec une adoption dépassant 90 % dès que l’entreprise compte plus de 10 salariés (source : Belacom) . On le sait, la valeur d’un CRM réside dans sa capacité à bénéficier d’une vue à 360° des interactions client, tous canaux confondus, et à fournir des données fiables. C’est encore plus vrai avec les IAs qui passent désormais au crible ces données pour en extirper toute la valeur.

L’interconnexion entre les outils de communications (téléphonie, collaboration, visioconférence, centre de contact) et ceux de gestion de la relation client est donc vitale. Leur convergence supporte et façonne la transformation digitale de la relation client en entreprise.

Or, l’évolution des environnements de centre de contact et de solutions CRM s’accompagne d’une diversification notable des modes d’interconnexion aujourd’hui disponibles pour les entreprises. L’ambition de cet article est de présenter de manière simplifiée ces principaux modes d’interconnexion, en les regroupant en 4 groupes classés par complexité de mise en œuvre croissante.

Le CTI est mort, vive le CTI !

Le CTI (Couplage Téléphonie Informatique) est un acronyme ancien, apparu au début des années 1990, lorsque les entreprises ont cherché à relier deux univers jusque-là indépendants : la téléphonie traditionnelle et l’informatique de bureau. L’objectif était d’améliorer la productivité des environnements de centre d’appels ou de support client. Sa principale fonctionnalité était la remontée de fiche d’identification sur les appels entrants.

Mais oubliez l’image du CTI des années 90 : aujourd’hui, c’est une boîte à outils cloud qui booste la productivité des agents. Si l’acronyme garde la trace de ses origines techniques, ses usages et les technologies qui le soutiennent sont désormais bien plus proches du logiciel cloud que du matériel téléphonique traditionnel.

Avec l’avènement de la téléphonie IP et des environnements cloud, le CTI s’est enrichi de nouvelles fonctionnalités : intégration (et non plus seulement Couplage) avec les CRM, click-to-call, distribution automatique des appels (ACD), transcription de messages vocaux, statistiques avancées ou encore intégration omnicanale permettant de gérer voix, messageries et emails dans une même interface.

Malgré ces évolutions technologiques fortes, de nombreux éditeurs maintiennent la terminologie de « CTI ». Chez ISI-COM par exemple, le fondateur de la société en parlait dès dans un livre publié en 1996 et en faisait un pilier de sa stratégie. Mais parler de CTI chez cet éditeur aujourd’hui, c’est évoquer une boîte à outils multi-technologique mise à destination des développeurs.

Les fonctionnalités CTI ne se limitent plus à l’identification d’appelant ou du click-to-call. Elles s’enrichissent par exemple chez Akio du routage intelligent, de l’enregistrement, de la transcription et du résumé d’appel, voire même de fonction d’anonymisation pour des questions de souveraineté.

Le connecteur sur étagère : simple, rapide à déployer, mais évolutif à son rythme

D’une certaine manière, le CTI était le premier connecteur du marché. S’il a posé les bases de l’interconnexion, le connecteur natif en a démocratisé l’accès.

Le connecteur natif – ou sur étagère, ou « out-of-the-box » – représente souvent le point d’entrée privilégié pour les entreprises qui veulent interconnecter leurs outils et optimiser leur fonctionnement. Il permet en quelques clics de relier une solution voix ou une plateforme de centre de contact à un CRM pour fluidifier le parcours agent sans engager de gros travaux IT.

Ce type de connecteur séduit par sa facilité et sa rapidité de mise en œuvre, mais – à l’instar du CTI – il offre des options limitées de personnalisation ou d’automatisation sophistiquée. Sa simplicité peut aussi devenir un piège (dépendance à l’éditeur, manque de flexibilité pour des besoins métiers spécifiques).

Malgré tout, les fonctionnalités vont du plus courant au plus évolué en fonction des connecteurs : log automatique des appels, synchronisation des contacts, création de tickets ou opportunités, envoi de SMS, etc. . Ce périmètre fonctionnel d’un connecteur évolue régulièrement, en fonction des attentes du marché, de l’évolution des technologies et des ressources disponibles chez l’éditeur.

Ainsi, Telavox a récemment renforcé son intégration avec Zendesk en y incluant l’automatisation avancée des flux, la vérification d’identité BankID pendant l’appel (pour les secteurs réglementés) et la journalisation des appels mobiles pour le travail à distance.

La montée en puissance des places de marché

Si leur terminologie peut varier – Apps Store, App Gallery, AppFoundry marketplace pour Genesys, App Directory chez Enreach, Rainbow Hub chez ALE, Integration Directory pour Eloquant, etc. – toutes les places de marché des éditeurs de solutions de communication multiplient désormais les connecteurs avec les plateformes CRM. Pour ne citer que l’acteur français historique Genesys, son AppFoundry présente presque une centaine de connecteurs dans la catégorie « CRM & Case Management ».

Le plus souvent y sont référencés les leaders du CRM comme Salesforce, HubSpot, ou encore Dynamics (selon les estimations, ces 2 acteurs représentent de 35 à 40% du marché en France). La présence des autres solutions va – quant à elle – dépendre de la stratégie des éditeurs et de leur positionnement sur le marché.

Précisons que le présent article s’intéresse prioritairement aux connecteurs publiés par les éditeurs de solutions de communication. Les places de marchés peuvent en effet présenter des connecteurs édités par des partenaires ou des intégrateurs (voir section sur les API). Ainsi pour 3CX, le connecteur Sellsy a été développé par Sellsy ; de même que pour Genesys, le connecteur Zoho a été développé par son partenaire Softphone.ai ; ou encore les connecteurs développés sur HubSpot, Dynamics ou Zoho CRM par des partenaires d’Amazon Connect.

Le webhook : pour une automatisation no-code et agile

Si les connecteurs natifs offrent une solution clé en main, les webhooks permettent d’aller plus loin sans entrer dans un développement sur mesure. Voyons comment.

Un webhook est comme un petit déclencheur invisible (un « trigger » disent les anglo-saxons) qui révolutionne l’automatisation sans une ligne de code en permettant à deux applications différentes—ici un CRM et une plateforme de communication —de se parler en temps réel, sans intervention humaine. Par exemple, dès qu’un nouvel appel se présente, un message est automatiquement envoyé au CRM pour l’avertir, et ce dernier peut alors agir en conséquence, par exemple en créant une fiche contact ou en ajoutant une note à une fiche existante.

Odigo offre ainsi la qualification automatisée de l’appel, le routage dynamique et la remontée d’information via webhook vers n’importe quel CRM. De même, Heedify facilite l’intégration de sa solution centre de contact avec Salesforce ou Microsoft Dynamics via Power Automate, permettant de déclencher des workflows et d’afficher la fiche client à chaque appel, sans développement spécifique.

L’automatisation via webhooks fait figure de solution intermédiaire pour étendre l’intégration. C’est une solution qui reste légère, agile, mais peut aussi montrer des limites pour des parcours complexes.

Un mode d’interconnexion omniprésente au sein des plateformes d’automatisation

Les plateformes d’automatisation (ou « hubs ») comme Zapier, Make, IFTT ou encore Power Automate, offrent une approche no-code / low-code qui permet à chacun de créer des flux automatisés entre une plateforme de communication et un CRM. Avec une différence importante qui est de proposer une approche agnostique des éditeurs. Elles permettent de connecter des centaines d’applications entre elles, mais leur utilisation peut devenir coûteuse à grande échelle et moins performante pour des intégrations temps réel.

Make.com est par exemple compatible avec la plupart des solutions majeures de VoIP, UCaaS et CCaaS, soit via des connecteurs directs que Make appelle des ‘modules officiels’ (Aircall, Diabolocom, Ringover, Teams, Zoom, RingCentral) ou via des API ouvertes (Genesys, Kiamo, Mitel, Avaya, 3CX, Wildix, Wazo, Enreach, Dstny, Telavox, Akio, Axialys, Eloquant, Heedify). Les connecteurs cachent toute la complexité de l’API en proposant un usage réellement sans code et en garantissant la sécurité (OAuth préconfiguré). Nous reviendrons sur la question des API dans le dernier chapitre de cet article .

Quand le no-code / low-code intègre les solutions CCaaS elles-mêmes

Si elles sont relativement ouvertes, agnostiques et offrent une ergonomie no-code / Low-code appréciable, les plateformes d’automatisation tierces présentent un inconvénient intrinsèque à leur mode de fonctionnement : elles impliquent de faire ‘sortir’ des données souvent sensibles vers un acteur tiers.

Que ce soit pour des questions de confiance, de sécurité ou de conformité réglementaire, de plus en plus d’éditeurs ont donc développé des modules d’ interconnexion CRM directement intégrés à leurs solutions.

Chez Akio par exemple, on utilise les technos URL ou toolbox pour permettre à des utilisateurs de créer eux-mêmes leur propre connecteur au sein de la plateforme. Le module est agnostique du CRM. Même logique pour le toolkit développé par Diabolocom, qui permet d’intégrer simplement les fonctionnalités de la plateforme dans un CRM tiers.

L’ère API et CPaaS : vers une intégration programmable et sur mesure

Si les webhooks et les hubs d’automatisation simplifient l’interconnexion, leurs capacités restent limitées à des scénarios prédéfinis. Pour les entreprises confrontées à des parcours clients complexes ou évolutifs, les API et les plateformes CPaaS offrent une plus grande flexibilité, mais nécessitent de renseigner manuellement de nombreux paramètres techniques ; elles requièrent donc une compréhension technique minimale.

Une API (Application Protocol Interface) permet de créer des ponts dynamiques entre systèmes, bien au-delà des simples notifications des webhooks. Par exemple, une API peut synchroniser en temps réel les données d’un appel avec un CRM, déclencher des workflows avancés (comme l’envoi d’un SMS personnalisé après une interaction), ou encore intégrer des fonctionnalités comme la transcription automatique ou l’analyse de sentiment.

Contrairement aux connecteurs natifs, les API s’adaptent aux processus métiers spécifiques, mais leur mise en œuvre exige des compétences techniques et un budget conséquent

Les plateformes CPaaS (comme Twilio, Vonage ou 8×8) franchissent quant à elles une étape supplémentaire en proposant des environnements clés en main pour concevoir des expériences communicantes multicanales. Elles intègrent nativement la voix, le SMS, la vidéo, les chatbots et même l’IA, sans nécessiter de développement lourd. Pour cette raison, elles s’adressent surtout aux organisations cherchant à innover et à scalabiliser leurs intégrations.

Par exemple, une entreprise peut utiliser Twilio Flex pour unifier ses canaux de communication (appels, chats, emails) dans une seule interface connectée à son CRM, tout en automatisant des tâches comme la création de tickets ou l’envoi de confirmations.

Les plateformes CPaaS réduisent ainsi les délais de déploiement, mais leur coût et leur complexité peuvent représenter un frein pour les petites structures. Les risques en termes de maintenance, de dépendance aux développeurs, ou de verrouillage technologique (migration difficile si l’API change) ne sont pas neutre également.

Ce qui est sûr, c’est que l’émergence du modèle API-first et la montée des plateformes CPaaS comme Twilio, 8×8, Sinch, Vonage, Amazon Connect ou RingCentral permettent aux entreprises d’orchestrer sur-mesure la synchronisation et le pilotage de tous leurs canaux de relation client.

Le cas particulier du connecteur OCF d’Orange Business

Dans un environnement technologique à la complexité croissante, les intégrateurs de solutions et les ESN sont régulièrement sollicités, à base projet, pour mettre en place des interconnexions à la carte.

Orange Business – branche intégrateur / ESN d’Orange – s’est positionné sur ce créneau avec une approche plus ‘industrielle’ en développant OCF, un connecteur à visée universelle. Certifié sur plus de 100 applicatifs, ce connecteur illustre une stratégie d’intégration “agnostique”, capable de garantir l’interopérabilité entre toute solution de téléphonie (IPBX, ToIP, cloud) et des CRM leaders ou sectoriels.

Pas de choix unique, mais une logique hybride au service des priorités de l’entreprise

Derrière ce panorama, une vérité s’impose : L’offre de modes d’interconnexion n’a jamais été aussi large ni aussi mature : du connecteur prêt à l’emploi à la plateforme CPaaS pilotée par API, en passant par le CTI agnostique et l’automatisation événementielle.

Mais faire un choix n’est pas une simple question choix technique ou IT ; c’est une décision stratégique. La maturité métier, la capacité d’investissement, les cycles d’évolution SI ou la pression sur la sécurité des flux, définissent plus sûrement le bon modèle qu’aucune fiche comparative. Ce sont finalement les priorités de l’entreprise, la nature des parcours client, et la capacité à maintenir l’équilibre entre simplicité d’usage et périmètre fonctionnel qui guident les arbitrages.

L’ensemble des modèles présentés ici a vocation à coexister sur le marché, chaque organisation étant amenée à bâtir son propre chemin d’intégration, en réponse à ses enjeux spécifiques et à l’évolution de son environnement.

Aucun modèle n’est universel : le bon choix dépend de vos priorités — maturité métier, budget, sécurité — et de votre capacité à mixer les solutions. L’avenir ? Une hybridation intelligente, où le centre de contact gère le temps réel, et le CRM capitalise sur la connaissance client. À vous de composer votre équation.

*Didier Lambert est le fondateur de Hubtic.fr

Avertissement
L’article s’appuie sur un parti pris méthodologique : il part des plateformes de communication pour explorer les modèles d’intégration qu’elles proposent. Un exercice similaire qui partirait des plateformes CRM serait instructif mais ce n’est pas l’objet de cet article. Les informations présentées proviennent des entretiens avec les éditeurs qui ont répondu à nos sollicitations, de l’exploration de leurs sites web et de leurs places de marché.
La liste des CRM n’est pas exhaustive et s’appuie sur les principaux acteurs commercialisés en France.

The post Votre CRM et votre solution de communication se parlent-ils vraiment ? appeared first on Silicon.fr.

Le spécialiste des infrastructures numériques Telehouse investit 275 millions de livres sterling dans un nouveau centre de données à Londres, Telehouse West Two. Ce site de neuf étages, prévu pour 2028, vise la certification BREEAM Excellent et sera alimenté à 100 % en énergie renouvelable. Telehouse International Corporation of Europe, filiale du groupe japonais KDDI, […]

L’article Telehouse renforce son ancrage à Londres avec un nouveau data centre durable est apparu en premier sur InformatiqueNews.fr.

— Permalink

— Permalink

Signal repose en partie sur AWS… et cela en a surpris beaucoup.

Meredith Whittaker le constate et s’en étonne. La présidente de la Fondation Signal s’en inquiète même : et si la concentration du pouvoir dans les mains de quelques hyperscalers était moins perçue qu’elle ne le pensait ?

Que la panne AWS soit « une leçon »

« Pourquoi Signal utilise-t-il AWS ? » n’est pas la question, poursuit l’intéressée. Il faut mesurer ce que toute plate-forme globale de communication en temps réel exige en matière d’infrastructure. La voix et la vidéo, en particulier, requièrent une architecture complexe pour gérer gigue et perte de paquets. Ces choses-là, AWS, Azure et GCP les fournissent à grande échelle. Pas les autres, tout du moins dans un contexte occidental.

Une telle infrastructure coûte des milliards à provisionner et à maintenir, en plus d’être largement amortissable, fait remarquer Meredith Whittaker. C’est pourquoi « presque tous ceux qui gèrent un service temps réel » (elle mentionne Mastodon, X et Palantir) s’appuient au moins en partie sur ces sociétés.

« Même si on avait les milliards pour, ce n’est pas qu’une question d’argent« , ajoute-t-elle. L’expertise est rare. Et très concentrée. D’ailleurs, l’outillage, les playbooks et le langage même du SRE moderne émanent des hyperscalers.

Dans la pratique, 3 ou 4 acteurs ont la main sur l’entièreté de la stack, résume M. Whittaker. Dans ces conditions, Signal « fait au possible » pour garantir une intégrité dans l’écosystème où il se trouve, grâce à du chiffrement de bout en bout.

La panne AWS, sera espère-t-elle, une leçon ; une mise en lumière des risques que suppose la « concentration du système nerveux de notre monde dans les mains de quelques acteurs ».

Signal sur AWS : une publicité limitée

Jusque-là, Signal n’avait pas fait grande publicité de son utilisation d’AWS.

On en trouve quelques traces sur son GitHub. Entre autres dans un ticket ouvert début 2021.

Dans une période d’exode marqué vers Signal, un utilisateur qui cherchait à migrer depuis WhatsApp s’était plaint d’un bug avec les liens servant à rejoindre un groupe.

« N’est-ce pas possible de monter en charge ?« , avait demandé un autre utilisateur, croyant savoir que Signal utilisait AWS. Un des contributeurs au projet le lui avait confirmé.

CloudFront, utilisé pendant un temps pour contourner la censure

AWS est aussi apparu à quelques reprises sur le blog de Signal. Notamment en 2018, dans le cadre d’une mise au point sur le domain fronting.

Cette technique, fonctionnant au niveau de la couche application, est traditionnellement utilisée pour contourner la censure. Elle permet de se connecter par HTTPS à un service interdit, tout en paraissant communiquer avec un site différent.

Pour la mettre en œuvre, Signal s’est, pendant un temps, appuyé sur Google App Engine, profitant du fait que couche de terminaison TLS était séparée de celle traitant les requêtes. Il l’a appliqué en Égypte, à Oman, au Qatar et aux Émirats arabes unis. Pour continuer à bloquer Signal, ces pays auraient dû bloquer google.com. Un pas qu’ils n’ont pas franchi.

La situation fut différente pour l’Iran. En application des sanctions américaines, Google n’autorisait pas le traitement, dans App Engine, de requêtes issues de ce pays. Mis sous pression pour lever cette interdiction, il avait, au contraire, fermé la porte au domain fronting au niveau mondial.

Signal s’était alors rabattu sur CloudFront, qui hébergeait quelques-uns des domaines les plus populaires (top 100 Alexa) dans les régions en question. Le projet étant open source, Amazon avait fini par avoir vent de la bascule… et avait rapidement fermé lui aussi les vannes du domain fronting.

Illustration générée par IA

The post « Oui, nous utilisons AWS » : Signal poussé à justifier son choix appeared first on Silicon.fr.

Dropbox renforce sa stratégie d’intelligence artificielle en intégrant Dash, son assistant de recherche universel, directement dans son application principale. L’objectif : aider les utilisateurs à retrouver plus facilement leurs fichiers, messages et contenus, qu’ils soient stockés sur Dropbox ou dans des outils tiers comme Slack, Google Workspace ou Canva. De la barre de recherche universelle à […]

L’article Dropbox intègre son IA Dash directement dans son application principale est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.

💾

Dans une initiative qui pourrait redéfinir l’efficacité énergétique des centres de données, la société chinoise HiCloud a mis en service le tout premier data center sous-marin au monde, principalement alimenté par l’énergie éolienne. Installée au large de Shanghai, cette infrastructure immerge des serveurs dans l’océan pour profiter du refroidissement naturel des courants marins, réduisant ainsi […]

L’article HiCloud immerge en Chine ses serveurs pour un refroidissement naturel est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.