« 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.
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 ?
« 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 » :
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.
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 (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é.
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.
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.
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.
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 .
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.
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.
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.
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.
J'ai un peu le même ressenti que celui exprimé dans cet article. Dans l'idée j'adore ce qu'est NextCloud et c'est heureux qu'il existe pour offrir une véritable alternative ouverte aux GAFAMs, mais j'ai toujours eu cette impression de lourdeur qui me bloque un peu.
J'ai un peu le même ressenti que celui exprimé dans cet article. Dans l'idée j'adore ce qu'est NextCloud et c'est heureux qu'il existe pour offrir une véritable alternative ouverte aux GAFAMs, mais j'ai toujours eu cette impression de lourdeur qui me bloque un peu.
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 ?
« 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 ».
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é.
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.
Témoignage d'une migration du cloud vers l'auto-hébergé, et des économies que ça a engendré.
Témoignage d'une migration du cloud vers l'auto-hébergé, et des économies que ça a engendré.
Dans les organisations, le partage de documents s’intensifie chaque jour. Qu’il s’agisse de bulletins de salaire, de contrats fournisseurs, de rapports d’audit ou de campagnes marketing, les équipes métiers doivent partager et récupérer des fichiers parfois critiques, souvent sans disposer d’outils réellement adaptés à leurs besoins. Entre les solutions grand public peu sécurisées et les […]
L’article Les Portails NetExplorer : le partage sécurisé pensé pour les métiers est apparu en premier sur InformatiqueNews.fr.
Entre abonnements imposés et tarifs qui explosent, le cloud propriétaire des géants américains transforme la flexibilité promise en dépendance subie. Les acteurs européens répliquent en misant sur l’open source pour reprendre la main sur leurs données et leurs budgets. Dans un climat international de plus en plus tendu, la prise de conscience du poids financier […]
L’article Abonnements forcés, tarifs en hausse : la facture cachée du cloud propriétaire… <br/><em>Florian Bertrand, NumSpot</em> est apparu en premier sur InformatiqueNews.fr.
À l’occasion d’Adobe MAX 2025, Adobe a annoncé deux nouveaux partenariats majeurs avec YouTube et Google Cloud, visant à fluidifier les workflows créatifs et à rendre les outils d’IA générative plus accessibles aux créateurs comme aux entreprises. Ces collaborations associent l’écosystème créatif d’Adobe, la puissance de la plateforme mondiale de YouTube et les modèles d’intelligence artificielle […]
L’article Adobe : un partenariat stratégique avec YouTube et Google Cloud pour l’IA est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.
Défaut logiciel dans le plan de contrôle, puis suppression par inadvertance d’une valeur de configuration : telles furent, le 9 octobre dernier, les sources d’un double incident ayant touché le CDN Azure Front Door.
L’accès à un grand nombre de portails de gestion de services s’en est trouvé perturbé pendant plus d’une demi-journée. L’Europe et l’Afrique furent les zones géographiques les plus touchées.
Un nouvel incident impliquant Azure Front Door est survenu ce 29 octobre. Cette fois, l’impact n’a pas été circonscrit aux portails de gestion. Microsoft liste une quinzaine de services affectés. Parmi eux, Azure SQL Database, Azure Virtual Desktop, Copilot for Security, Purview, Sentinel et Entra ID (sur certaines composantes dont l’IAM et l’interface de gestion des utilisateurs).
Le déclencheur fut un changement de configuration de locataire Azure Front Door. Il a introduit un état invalide empêchant le chargement d’un grand nombre de nœuds. Avec, pour conséquence, une hausse des latences, voire des erreurs de connexion sur les services aval.
Microsoft a alors bloqué tout changement de configuration pour éviter la propagation de cet état défaillant. Il a ensuite amorcé un rollback vers la dernière « bonne version » de configuration. Pour éviter une surcharge, le trafic a dû être rééquilibré de façon progressive. Il s’est donc écoulé près de 10 heures entre le début de l’incident et sa résolution officielle (1 heure du matin en France ce 30 octobre, les changements de configuration par les clients étant restés bloqués un peu plus longtemps).
Cet état invalide est passé à travers les mécanismes de protection en raison d’un défaut logiciel, nous explique-t-on.
Le motif « défaut logiciel » a également été invoqué des suites de l’incident du 9 octobre. Plus précisément sur la première phase, qui a duré environ 8 heures.
Le souci se trouvait dans le plan de contrôle d’Azure Front Door, au niveau des informations communiquées au plan des données dans le cadre des opérations de création et de modification de profils CDN initiées par le client.
La version problématique du plan de contrôle avait été déployée 6 semaines en amont. Une séquence spécifique d’opérations de mise à jour de profils générait des métadonnées erronées faisant crasher le plan de données.
Les protections automatisées ont détecté le problème suffisamment tôt pour éviter une propagation au-delà du plan de données. De surcroît, l’ancienne version de plan de contrôle tournant toujours, il a été possible d’y rediriger toutes les requêtes.
Dans ce contexte, le 9 octobre, un processus d’assainissement de la configuration contenant les métadonnées erronées a été lancé. Comme le système de protection automatisé bloquait les mises à jour de profils concernées, un contournement temporaire a été mis en place. Il a toutefois ouvert la porte à la propagation des métadonnées problématiques,.. et à la perturbation d’Azure Front Door. Essentiellement, donc, en Afrique et en Europe.
La redistribution de charge qui s’est ensuivie, assortie d’une augmentation du trafic avec le démarrage des heures de bureau, a tant fait croître l’utilisation de ressources que des seuils critiques ont fini par être dépassés. Une couche de protection supplémentaire s’est alors mise en marche pour distribuer encore davantage le trafic. Il a cependant fallu des interventions manuelles lorsque le processus automatisé prenait trop de temps.
En début d’après-midi (heure française), la disponibilité d’Azure Front Door était pleinement rétablie. Dans la soirée, la retour à la normale ayant été validé, Microsoft a entrepris de refaire passer tout le trafic par son CDN.
C’est là qu’un deuxième problème est survenu. Un script destiné à mettre à jour la config de load balancing a supprimé une valeur de configuration. La cause : l’API qu’il utilisait n’avait pas connaissance de cette valeur.
Les vérifications d’intégrité de l’endpoint Azure Front Door ont alors commencé à échouer. À mesure que les filtres réseau ont été mis à jour, le problème s’est propagé. Il a fallu environ 4 heures pour le résoudre. Entre-temps, environ la moitié des clients ayant utilisé les portails de gestion de services Azure ont subi une forme d’impact.
Illustration générée par IA
The post Microsoft Azure à nouveau perturbé par un problème de CDN appeared first on Silicon.fr.
Connexion