« SIEM : 6 fournisseurs dominent un marché qui se densifie ».

Ainsi avions-nous titré, au printemps 2024, notre synthèse de ce qui était alors le dernier Magic Quadrant consacré à ce marché. Gartner avait effectivement classé 22 offreurs, dépassant le seuil des 20 auquel il se tient généralement.

Ils furent 6 à faire leur entrée à cette occasion. Un directement chez les « visionnaires » (Google). Les autres chez les « acteurs de niche » (Logz.io, NetWitness, Odyssey, QAX, Venustech).

4 entrants pour 9 sortants : un Magic Quadrant à périmètre nettement réduit

Dans le Magic Quadrant du SIEM version 2025, plus de Logz.io, de NetWitness, d’Odyssey ni de Venustech. Ils ne sont pas les seuls à disparaître. Devo Technology, IBM, LogRhythm, Logpoint et OpenText suivent le même chemin.

Pour LogRhythm, c’est dû à sa fusion avec Exabeam (finalisée en juillet 2024). IBM ne remplit quant à lui plus le cahier des charges technique de Gartner depuis qu’il a vendu QRadar SaaS à Palo Alto Networks.

Pour les autres, c’est partagé. Logpoint n’a pas satisfait à tous les critères fonctionnels. Devo Technology, Odyssey et Venustech, aux critères business. Logz.io, Netwitness et OpenText, aux uns et aux autres.

Les critères techniques ont globalement peu évolué par rapport à l’an dernier. Mais quelques seuils ont été relevés, comme le volume miminal de connecteurs pour la capture et le streaming de données en complément à la collecte de logs.

D’une année sur l’autre, les mêmes fonctionnalités sont restées « à la carte ». Il fallait, d’une part, en fournir au moins 2 sur les 4 suivantes :

• Recherche fédérée sur environnement SIEM distribué
• Recherche hors des dépôts du SIEM
• Intégration de data lakes tiers
• Disponibilité d’un stockage de long terme (avec capacité de rappel « chaud » sur 365 jours)

D’autre part, fournir au moins 2 des 3 suivantes :

• SOAR (automatisation et orchestration de tâches communes)
• Threat intelligence
• Capacités fondées sur l’analyse comportementale ou la data science/le machine learning

Sur le volet business aussi, des seuils ont été relevés. D’une part, il fallait avoir dégagé, entre mars 2024 et mars 2025, au moins 85 M$ de CA licences + maintenance sur les produits cloud*/SaaS ou bien disposer de 500 clients en production avec des contrats en direct sur ce même type de produits (les seuils précédents étaient à 75 M$ et 200 clients). De l’autre, avoir réalisé au moins 25 % de ce CA auprès de clients localisés hors de la région dans laquelle se trouve le siège social du fournisseur ; ou bien disposer d’au moins 25 % de clients respectant de même périmètre géographique (les seuils précédents étaient à 15 % de CA et 30 clients).

Platform or not platform ? Des divergences qui structurent le marché

Le relèvement des seuils business est aussi, explique Gartner, la conséquence de la présence de « gros » fournisseurs parmi les 4 entrants de cette année (CrowdStrike, Datadog, Graylog et Palo Alto Networks).

CrowdStrike et Palo Alto Networks font partie des fournisseurs qui ont, comme Microsoft entre autres, intégré leur SIEM dans des offres plus larges avec un modèle de licence adapté. Certains, plutôt que de jouer la carte de la plate-forme, axent leur discours sur les capacités d’ingestion à grande échelle.

Une opposition existe aussi entre ceux qui, pour réduire la complexité, poussent la combinaison du SIEM avec d’autres parties de la stack de sécurité. Et ceux qui, en vue de ce même objectif, prônent un usage stratégie de l’augmentation des workflows (IA, automatisation).

Ces divergences contribuent à faire évoluer le paysage concurrentiel. À tel point que Gartner a priorisé, dans son évaluation, la vision que les fournisseurs ont du SIEM et leur capacité à faire adopter cette vision au marché.

17 fournisseurs, toujours 6 « leaders »

Le positionnement au sein du Magic Quadrant résulte de la combinaison d’évaluations sur deux axes. L’un prospectif (« vision »), centré sur les stratégies (sectorielle, géographique, commerciale, marketing, produit…). L’autre censé refléter la capacité à répondre effectivement à la demande (« exécution » : expérience client, performance avant-vente, qualité des produits/services…).

Sur l’axe « exécution », la situation est la suivante :

Rang	Fournisseur	Évolution annuelle
1	Splunk	=
2	Microsoft	=
3	Google	+ 8
4	Rapid7	+ 3
5	Palo Alto Networks	nouvel entrant
6	Securonix	– 2
7	Exabeam	– 1
8	Fortinet	=
9	Gurucul	=
10	Elastic	+ 4
11	CrowdStrike	nouvel entrant
12	Sumo Logic	– 7
13	Huawei	+ 2
14	Datadog	nouvel entrant
15	QAX	+ 6
16	ManageEngine	+ 1
17	Graylog	nouvel entrant

Sur l’axe « vision » :

Rang	Fournisseur	Évolution annuelle
1	Google	+ 4
2	Securonix	+ 4
3	Microsoft	– 1
4	Gurucul	– 3
5	Exabeam	– 1
6	Splunk	– 3
7	Elastic	+ 2
8	CrowdStrike	nouvel entrant
9	Datadog	nouvel entrant
10	Huawei	+ 6
11	Palo Alto Networks	nouvel entrant
12 (ex aequo)	QAX	+ 6
12 (ex aequo)	Fortinet	+ 2
12 (ex aequo)	Rapid7	+ 1
15	Sumo Logic	– 3
16	Graylog	nouvel entrant
17	ManageEngine	+ 5

Six fournissent se trouvent dans le carré des « leaders » : Exabeam, Google, Gurucul, Microsoft, Securonix et Splunk.

Exabeam demeure plus cher que la moyenne

L’an dernier, Gartner avait salué l’UI d’Exabeam, « très en phase » avec les besoins des analystes sécurité. Il avait aussi apprécié le scoring dynamique et les capacités de traitement des flux tiers par recherche fédérée.
Le cabinet américain avait, en revanche, pointé une courbe d’apprentissage plus longue que sur les autres SIEM. Et relevé une tarification plus élevée que la moyenne, en plus d’une tendance à se focaliser sur les grandes entreprises.

Cette année encore, l’UI fait mouche. Comme le scoring et la recherche fédérée. S’y ajoutent l’assistant Exabeam Copilot (qui simplifie le tri et la priorisation des cas) et une marketplace « bien fournie en contenu », notamment sur la menace interne, les règles de corrélation et les dashboards extensibles.
La tarification au-dessus de la moyenne reste d’actualité. La courbe d’apprentissage aussi, mais pour une brique en particulier : Advanced Analytics (moteur legacy de détection comportementale). On surveillera par ailleurs l’effet latent de la fusion avec LogRhythm (annoncée en mai 2024) en matière d’allocation des ressources de développement produit.

Google peut progresser sur l’UEBA

Avec son offre Chronicle, Google Cloud avait fait son entrée au Magic Quadrant du SIEM l’an dernier. Il était classé chez les « visionnaires » (résultat insuffisant sur l’axe « exécution » pour être leader).

Depuis, Chronicle est devenu SecOps. La plate-forme se distingue sur les requêtes « avancées et complexes », selon Gartner. La fédération et le multilocataire la rendent attractive pour les MSSP comme pour les grandes organisations qui ont besoin de plusieurs instances de SIEM. Autre bon point : l’injection d’IA sur un large spectre de workflows, en plus de capacités d’automatisation « bien intégrées ».

On notera qu’il n’existe pas de version on-prem de SecOps. S’y ajoute une UI complexe, au sens où Google favorise une approche CLI (pour la création de requêtes, par exemple) dont l’implémentation et l’exploitation supposent des compétences. Il y a également de la marge de progression sur l’UEBA, qui manque de use cases embarqués qu’on trouve généralement chez les autres « leaders » du SIEM.

Gurucul : un prix potentiellement difficile à justifier

L’an dernier, Gurucul était lui aussi chez les « visionnaires ».

Il est crédité d’un bon point pour son programme marketing, dont l’extension est corrélée à un taux de renouvellements plus élevé que la moyenne. Gartner apprécie aussi ses roadmaps et sa capacité à délivrer des fonctionnalités de façon consistante. Bon point également pour la partie gestion des données, qui apporte de la flexibilité.

Le prix est beaucoup plus élevé que chez les principaux concurrents, si bien qu’il peut être difficile de prouver la valeur de certaines fonctionnalités « avancées ». Globalement, la solution est plutôt adaptée aux acheteurs qui présentent des cas d’usage complexes. Attention aussi sur la partie « augmentation » des workflows (automatisation, orchestration) : sur le plan fonctionnel, Gurucul est en retard sur les autres « leaders ».

Chez Microsoft, les dépendances à Azure perdurent

L’an dernier, Gartner avait salué les passerelles établies entre le SIEM Sentinel et le reste de l’écosystème de Microsoft (SOAR, CASB, protection des identités et des terminaux…). Il avait aussi apprécié la couverture MITRE ATT&CK. Et les capacités de personnalisation, tant au niveau des modèles de détection de menaces que de l’UI de threat intelligence.
Le cabinet américain n’en avait pas dit autant au sujet du reporting de conformité, jugé limité. Il y avait ajouté la dépendance à des services Azure pour certaines fonctionnalités… et pour l’hébergement de la solution.

Cette année, Microsoft conserve son bon point pour le niveau de couverture de la matrice MITRE ATT&CK. Même chose pour les intégrations avec le reste de son écosystème. Gartner y ajoute l’extension de la prise en charge d’outils tiers, l’intégration d’IA en particulier sur la partie corrélation, et les capacités de personnalisation du tableau de bord de renseignement sur les menaces.

Microsoft peut lui aussi se révéler plus cher que la concurrence, surtout lorsqu’on ingère des données depuis des sources externes. Les dépendances à Azure valent toujours (pour l’intégration de sources de télémétrie tierces, par exemple), y compris pour l’hébergement (SaaS uniquement).

Securonix, en retard sur l’augmentation des workflows

L’an dernier, Securonix s’était distingué pour sa gestion des sources de données tierces et des flux de threat intelligence. Gartner avait aussi salué l’aide fournie pour améliorer la configuration du SIEM (identification des sources de données manquantes, des modèles d’analyse pertinents…).
Il avait moins apprécié le modèle économique fondé exclusivement sur les EPS (événements par seconde). Ainsi que la prise en main. Qui, expliquait-il, nécessitait « plus de services professionnels que la moyenne ». En tout cas pour les déploiements cloud.

Cette année, un bon point va à la gestion des data lakes tiers – et à la flexibilité que cela apporte. Securonix se distingue aussi sur l’UEBA (capacité à gérer des use cases avancés), assorti de « capacités exhaustives » de test et de tuning. Il dédie par ailleurs au développement produit une équipe « plus grosse que la moyenne » [de l’ensemble des fournisseurs classés au Magic Quadrant du SIEM].
S’il existe une brique d’augmentation de workflows, elle est en retard sur celles des autres « leaders », tant au niveau des fonctionnalités que des intégrations. Gartner souligne aussi une dépendance au risk scoring susceptible de réduire la capacité à créer manuellement des requêtes. Et note que la croissance de la base client est plus faible que chez d’autres « leaders ».

Splunk traduit sa vision moins vite que la concurrence

L’an dernier, Splunk s’était distingué avec son UI, en particulier pour les capacités de personnalisation. Il avait aussi pour lui une bibliothèque d’intégrations exhaustive, SOAR en tête. Gartner avait aussi salué la composante observabilité, couplée à la recherche fédérée et aux capacités d’analyse sur les data stores tiers.
Bien que flexible, la tarification apparaissait plus élevée que la moyenne. Et la solution, complexe, tout du moins au niveau de l’implémentation. Gartner avait aussi souligné le fait que les effectifs étaient majoritairement localisés en Amérique du Nord… et l’impact potentiel que cela pouvait avoir sur le support client.

Cette année, l’un des bons points va à la marketplace de contenus, doublée de la richesse des ressources développées par la communauté. Un autre va au catalogue d’intégrations avec les produits de sécurité, dont ceux de Cisco. Gartner souligne aussi les possibilités de personnalisation de la solution pour le développement de workflows et de dashboards.
L’augmentation de workflows n’est pas le fort de Splunk, qui affiche lui aussi du retard sur ses principaux concurrents. Du retard face à ces mêmes acteurs, il en a aussi au niveau de la roadmap, reflet d’une stratégie encore centrée sur l’intégration dans l’optique de constituer une plate-forme TDIR unifiée. Quant aux possibilités de personnalisation, elles supposent une certaine complexité qui pourrait rebuter les organisations les moins matures.

* Comprendre « cloud-native« , c’est-à-dire conçu pour exploiter les caractéristiques du cloud.

Illustration © Brues – Shutterstock

The post SIEM : le marché se structure sur des visions opposées appeared first on Silicon.fr.

Doit-on attendre d’un fournisseur de PAM qu’il propose une brique de CIEM (gestion des droits d’accès à l’infrastructure cloud) ?

Gartner considère désormais qu’il s’agit d’une fonctionnalité « commune ». Il la catégorise tout du moins ainsi dans son dernier Magic Quadrant dédié à ce marché.

Dans l’édition précédente, le CIEM était facultatif. Il n’est pas le seul à avoir rejoint le cahier des charges technique cette année. La gestion des secrets pour les workloads a suivi la même trajectoire. Idem pour la gestion du cycle de vie des comptes à privilèges et celle des accès distants à privilèges.

De même, certains critères jugés « communs » l’an dernier sont devenus « obligatoires ». En l’occurrence, la découverte de comptes à privilèges, l’enregistrement des sessions à privilèges et la gestion des privilèges juste-à-temps.

12 fournisseurs, 3 « leaders »

Pour espérer figurer dans le Magic Quadrant du PAM, il y avait 7 critères « obligatoires » à respecter :

• Gestion et mise en œuvre centralisées des accès à privilèges, en contrôlant soit l’accès à des comptes et à des authentifiants, soit l’exécution de commandes, soit les deux
• Gestion et octroi des accès à privilèges sur base temporaire aux utilisateurs autorisés
• Découverte de comptes à privilèges
• Conservation et gestion des authentifiants pour les comptes à privilèges
• Gestion, supervision, enregistrement et audit des sessions à privilèges
• Gestion des privilèges juste-à-temps
• Administration à base de rôles, avec gestion centralisée des politiques d’accès aux authentifiants

Il fallait par ailleurs fournir au moins 5 des 8 éléments « communs » suivants :

• Contrôle de l’élévation de privilèges par agent sur Windows, UNIX/Linux et macOS
• Gestion des secrets pour les workloads

• Gestion du cycle de vie des comptes à privilèges
• CIEM
• Gestion des accès distants à privilèges
• Automatisation des tâches routinières liées aux opérations à privilèges orchestrées et/ou exécutées à travers plusieurs systèmes
• ZSP (zero standing privileges) : pas d’élévation juste-à-temps vers un compte ou un rôle existant, mais création de rôles et de permissions éphémères
• Analyse des patterns de privilèges, des mauvaises configs, des comportements d’accès, des anomalies

Le positionnement au sein du Magic Quadrant résulte d’évaluations sur deux axes. L’un, appelé « vision », est prospectif. Il est centré sur les stratégies (sectorielle, géographique, commerciale, marketing, produit…). L’autre, dit « exécution », reflète la capacité à répondre effectivement à la demande (expérience client, performance avant-vente, qualité des produits/services…).

Sur l’axe « exécution », la situation est la suivante :

Rang	Fournisseur	Évolution annuelle
1	BeyondTrust	+ 3
2	CyberArk	+ 1
3	ARCON	– 2
4	Delinea	– 2
5	Savyint	nouvel entrant
6	ManageEngine	– 1
7	Segura	nouvel entrant
8	One Identity	– 1
9	Keeper Security	nouvel entrant
10	WALLIX	– 4
11	Netwrix	– 2
12	StrongDM	nouvel entrant

Sur l’axe « vision » :

Rang	Fournisseur	Évolution annuelle
1	CyberArk	=
2	BeyondTrust	+ 1
3	Delinea	– 1
4	WALLIX	=
5	One Identity	=
6	ARCON	+ 1
7	ManageEngine	– 1
8	Savyint	nouvel entrant
9	StrongDM	nouvel entrant
10	Segura	nouvel entrant
11	Netwrix	– 3
12	Keeper Security	nouvel entrant

Les trois « leaders » sont les mêmes qu’en 2024. Dans l’ordre alphabétique : BeyondTrust, CyberArk et Delinea. Le français WALLIX reste chez les « visionnaires », à plus forte raison avec son recul sur l’axe « exécution ».

BeyondTrust peut progresser sur les identités machine

BeyondTrust reste, d’après Gartner, parmi les meilleurs sur le remote PAM et le juste-à-temps. Il se distingue aussi sur le CIEM. Si ses prix restent globalement au-dessus de la moyenne du marché, la partie SaaS fait désormais exception sur plusieurs scénarios évalués, en conséquence du lancement des bundles Essentials, Plus et Flex dans la plate-forme Pathfinder. Bons points également pour la stratégie commerciale (réseau de vente, remises sur engagement, cross-selling efficace) et l’accompagnement client (customer advisory boards, notamment, ainsi que plusieurs niveaux de formation, dont du gratuit).

L’offre de BeyondTrust manque encore de maturité sur la gestion des identités de workloads et des secrets (pas de possibilité de gérer les gestionnaires tiers, notamment). Au global, les innovations ont manqué sur l’année écoulée, se limitant à de l’intégration/unification. À cela s’ajoute un retard, par rapport aux autres « leaders », sur l’exploitation de la GenAI dans la gestion des sessions. Attention aussi au support technique, jugé améliorable par certains clients – comme, d’ailleurs, le paramétrage initial (qui peut s’avérer complexe) ainsi que l’UI et la navigation.

CyberArk reste parmi les plus chers du marché

« Mature » sur l’ensemble de son offre, CyberArk se distingue particulièrement sur la gestion des identités de workloads et des secrets, ainsi que sur le PEDM Windows. Il a aussi pour lui son IA CORA, appliquée entre autres au résumé de sessions, à la détection d’anomalies au niveau des secrets et à la recommandation de règles. Autre point positif : le recueil du feedback client, entre sondages et customer advisory board. Gartner apprécie également la stratégie géographique (capacité de delivery local) et l’extension sectorielle de l’offre, en particulier vers les services financiers et le secteur public.

L’élévation de privilèges exige des produits distincts pour UNIX et Linux, et ils ne sont pas à parité fonctionnelle. Au global, les prix restent parmi les plus élevés du marché, et CyberArk ne pratique toujours pas de remises sur engagement multiannuel. Il a de la marge de progression sur le support, comme sur le paramétrage initial (complexe) et les upgrades de son PAM autohébergé. On portera aussi attention à l’évolution de l’activité des suites de l’acquisition par Palo Alto Networks (annoncée en juillet).

Delinea, en retard sur le remote PAM

Delinea reste un des meilleurs sur le PEDM UNIX/Linux. Il se distingue aussi sur la gestion des identités de workloads et des secrets, comme sur le CIEM. Gartner salue autant le support technique que la collecte de feedback. Il souligne aussi la facilité d’utilisation de la solution (moteurs unifiés, console de gestion unique, bonne couverture sur les rapports d’intégrité). Ainsi que la disponibilité d’un agent qui exploite le contexte pour automatiser les décisions d’accès dans les environnements cloud.

Delinea est, en revanche, moins mature sur le remote PAM (manque d’enregistrement en self-service, de collaboration multiutilisateurs, de création à la demande de jetons à usage unique pour les identités externes…). En fonction des scénarios testés, la tarification est « inégale » : sous la moyenne du marché pour les entreprises de moins de 1000 employés, au-dessus pour les plus grandes. Attention aussi au fait que la gestion des authentifiants à privilèges et la découverte de comptes peut nécessiter une personnalisation par PowerShell. Gartner fait par ailleurs remarque que la croissance des revenus de Delinea a ralenti, tout comme celle des investissements en ventes/marketing.

Le SaaS a du mal à prendre chez WALLIX

Bon sur les accès distants, WALLIX garde par ailleurs son avantage sur le PAM pour les systèmes cyber-physiques. Il bénéficie d’ailleurs d’une présence importante dans la production industrielle – tout comme dans les services financiers et le secteur public. Gartner salue l’efficacité de son support, la facilité d’usage de sa solution et l’engagement client régulier (dont customer advisory board).

La découverte de comptes s’avère limitée (axée sur Active Directory) et le PAM JIT reste immature (dépendant d’intégrations workflow/ITSM). Comme chez Delinea, la tarification a tendance à être avantageuse pour les plus petites organisations, moins pour les plus grandes. Gartner note aussi que parmi les fournisseurs qui proposent du SaaS, WALLIX est celui qui a signé le moins de contrats (la majorité de ses clients implémentent encore sur site). Il ajoute, sous son prisme américain, l’absence de certifications communes chez des concurrents (FedRAMP, FIPS, SOC 2).

Illustration générée par IA

The post Gestion des accès à privilèges (PAM) : en 2025, quel cahier des charges technique ? appeared first on Silicon.fr.

Alibaba vient-il de « faire une DeepSeek » ?

Le groupe chinois est en tout cas parvenu, comme son compatriote en début d’année, à attirer l’attention avec un article scientifique qui touche à la frugalité de l’IA.

La planification de l’autoscaling descendue au niveau des tokens

DeepSeek avait causé un électrochoc en présentant des LLM entraînés avec nettement moins de ressources de calcul que les modèles référents du marché.

Du côté d’Alibaba, la logique est la même, mais sur la phase d’inférence. Elle implique un système de pooling GPU nommé Aegaeon.

En la matière, deux grandes approches sont traditionnellement mises en œuvre : le multiplexage et l’autoscaling.

Le multiplexage place plusieurs instances de modèles sur chaque GPU, avec un partage spatial ou temporel (technologie NVIDIA MPS). Le mécanisme est limité par la quantité de VRAM disponible.

La méthode autoscaling est plus « agressive ». Elle adapte le placement du modèle au fil du temps, en le chargeant depuis la mémoire de l’hôte ou depuis un support externe.

L’efficacité de l’autoscaling est limitée par le ratio de modèles actifs au sein des workloads. Or, la durée d’exécution des requêtes LLM fait qu’à tout moment, un grand nombre de modèles sont actifs, même si les invocations sont sporadiques. Lorsque toutes les instances GPU sont occupées par des modèles actifs, les nouvelles requêtes doivent attendre (on ne peut pas associer en un même lot des opérations de préremplissage et de décodage liées à des modèles différents). Dans ce contexte, réserver moins d’instances qu’il n’y a de modèles accroît le risque de compromettre le respect des SLO.

Pour dépasser cette limite, Alibaba a mis en place un mécanisme planification non au niveau des requêtes, mais des tokens. L’approche avait déjà été expérimentée en configuration monomodèle. En multi, elle est d’autant plus critique que le nombre de batchs augmente (puisqu’on ne peut, donc, pas batcher les requêtes de modèles différents).

Des partitions distinctes pour préremplissage et décodage

Aegaeon planifie en parallèle l’exécution d’une requête et l’autoscaling. Étant donné un ensemble d’instances GPU et des SLO cibles (TTFT, latence du premier token ; TBT, latence entre tokens), il choisit la tâche suivante (prefill ou décodage) pour chaque instance. Et opère éventuellement un autoscaling préemptif si une tâche planifiée utilise un autre modèle que celui actif.

Alibaba a opté pour une désagrégation des phases de préremplissage et de décodage. Il a ainsi divisé le pool GPU en deux partitions. La partie décodage utilise une planification en round-robin pondéré, censée maximiser le respect du TBT. Le prefill exploite un système de planification groupée : on réunit les requêtes qui visent un même modèle, tout en maintenant une approche « premier arrivée, premier servi » pour éviter tout privation de ressources. Les tâches sont ajoutées à un groupe existant si c’est possible. Sinon, Aegaeon en crée un et l’attache à la file d’attente la moins peuplée (chaque instance a sa file). La taille de batch est plafonnée à 1, vu la relative linéarité entre le nombre de tokens et le temps d’exécution – et du fait que de plus petits batchs réduisent les délais d’attente.

Réutiliser pour ne pas (tout) réinitialiser

Les solutions d’autoscaling préemptif tendent à se focaliser sur l’accélération du chargement du modèle. Alibaba Cloud s’est intéressé aux autres étapes de la procédure : réinitialisation du moteur, gestion de la mémoire et transferts du cache clé-valeur.

La réinitialisation du moteur est une séquence qui, à défaut d’optimisation, peut prendre des dizaines de secondes. Elle comprend notamment l’initialisation du cache clé-valeur, le chargement des poids, le profilage et l’optimisation (allocation d’espace pour le cache clé-valeur) et le démarrage d’orchestrateurs comme Ray destinés à distribuer l’exécution.

Alibaba s’est figuré que l’initialisation de ces différents composants pouvait être réutilisée de manière sûre entre modèles. Ainsi, Aegaeon n’initialise le moteur qu’une fois par instance, mettant tous les éléments en cache sauf poids et cache clé-valeur. Pour ce dernier, il exploite un pool préattribué dans la mémoire de l’hôte, évitant de devoir épingler des pages pendant l’autoscaling. L’ensemble réduit la latence de plus de 80 %.

Les événements CUDA mis à profit

La gestion mémoire est quant à elle rendue explicite. À l’appui, entre autres, d’un tampon VRAM autogéré et d’un cache clé-valeur « unifié » (chaque zone, en VRAM ou DRAM, est divisée en fragments de taille fixe qui accueillent différents blocs en fonction de la forme du cache).

Pour ce qui est des transferts du cache clé-valeur entre hôte et GPU, l’enjeu est de permettre leur chevauchement tout en minimisant les conditions de concurrence des données. Les événements CUDA ont été mis à contribution dans ce but, pour suivre individuellement les transferts.

De 1192 à 213 GPU pour le Model Studio d’Alibaba Cloud

Pour évaluer Aegaeon, Alibaba a choisi une config à deux nœuds de 8 GPU H80-80, avec 2 To de DRAM (DDR5) et 192 CPU Xeon Platinum 8469C. Il y a fait tourner des LLM de plusieurs familles (Qwen, Llama, InternLM, Yi, etc., essentiellement de 6 à 14 milliards de paramètres) sur le dataset ShareGPT et deux déclinaisons « augmentées » (inputs et outputs allongés). La comparaison a été faite avec MuxServer et ServerlessLLM, deux solutions qui adoptent respectivement le multiplexage et l’autoscaling.

Illustrant les limites du multiplexage, MuxServer a systématiquement refusé de placer plus de 2 modèles par GPU, en raison du manque de VRAM.

À un débit de 0,1 requête/seconde, Aegaeon soutient un débit utile doublé par rapport à ServerlessLLM. Il gère jusqu’à 70 modèles avec 10 instances de décodage. ServerlessLLM souffre de longs temps d’attente. ServerlessLLM+ (implémentation ad hoc ajoutant une planification Shortest Job First à partir d’un oracle fondé sur les longueurs d’output) atténue l’effet, mais la performance se dégrade inévitablement avec davantage de modèles actifs.

À 0,5 requête/s, l’écart de débit utile est de 2,5 par rapport à ServerlessLLM.

Cet écart se maintient sur les datasets « augmentés ». Et, quoique dans une moindre mesure, avec des SLO plus stricts laissant moins de marge de pooling. Cela se vérifie aussi sur des configs plus restreintes en hardware (par exemple, un nœud de 4 GPU A10). Pour Alibaba, c’est la preuve qu’Aegaeon est potentiellement applicable à un grand éventail de workloads.

Le système alimente, depuis quelques mois, le Model Studio d’Alibaba Cloud. Il fonctionne sur un cluster multirégion de 213 GPU H20 servant 47 modèles de 1,8 à 72 milliards de paramètres. Ces modèles étaient, à l’origine, servis par 1192 GPU H20. Le parc s’est donc réduit de 82 %.

Illustration principale générée par IA

The post « 82 % de GPU en moins » : Alibaba fait du DeepSeek, mais pour l’inférence appeared first on Silicon.fr.

Consciente des enjeux de sécurité et de gouvernance, OpenAI adopte une approche progressive pour l’ouverture de son navigateur Atlas aux entreprises.

Dans la nomenclature Cigref des métiers du SI, ne cherchez plus le chief digital officer : son profil a été supprimé.

Cette fonction relève désormais davantage d’un rôle transversal que d’un métier à part entière, nous explique-t-on. Son exercice est réparti entre plusieurs directions métiers. Lesquelles exploitent des outils numériques dont la DSI n’a pas toujours la gestion, tout en contribuant de plus en plus à la structuration de l’offre digitale destinée aux clients finaux. Quant aux produits orientés vers des clients internes, leur structure est souvent assurée par la direction du numérique.

Un autre profil a disparu d’une année à l’autre : le responsable marketing de la DSI. Constat : il n’existe pratiquement plus en tant que tel, en tout cas dans les organisations membres du groupe de travail ayant élaboré la nomenclature. Ses missions ont été réparties sur plusieurs services ou attribuées aux CIO. Dans quelques organisations, la communication est portée par un pôle plutôt que par une personne.

Dans la version 2024 de sa nomenclature*, le Cigref avait souligné que la fonction de chief digital officer pouvait être dévolue au DSI. Et que l’activité « marketing de la DSI » ne devrait pas concerner une seule personne, mais se disséminer dans l’organisation, à des niveaux différents suivant les métiers.

Le profil DevOps, envisagé l’an dernier, intégré cette année

En 2024, le Cigref avait envisagé d’intégrer le profil DevOps. Cela ne s’était pas fait, faute de consensus. Certains membres considéraient en effet que ses compétences venaient compléter des métiers existants. D’autres estimaient que la fonction pouvait être couverte en adaptant les processus et les activités des métiers IT. Il en avait été conclu que le concept même de DevOps « [cherchait] encore à se formaliser ».

La posture a évolué depuis : voilà le profil intégré à la nomenclature version 2025. Il fait généralement suite à un début de carrière en tant que développeur, administrateur systèmes et réseaux, intégrateur d’applications ou encore chargé de support de production. En fonction du niveau de séniorité, il peut être une passerelle vers des emplois d’expert SRE, d’architecture technique ou de tech lead, ou de management.

Le Cigref retient quatre indicateurs de performance pour le métier DevOps :

• Pourcentrage de déploiements à l’origine des incidents
• Niveau de qualité du code livré
• Délai de promotion des changements
• Temps moyen pour restaurer le service après un incident

Pour ce qui est des compétences nécessaires, l’association met à égal niveau (3/5) :

• Déploiement de solution
• Fourniture de service
• Gestion des changements métier
• Gestion des problèmes
• Gestion des risques

Concernant les notions transversales utiles au métier DevOps :

• Sécurité (4/5)
• Utilisabilité (3)
• Développement durable (3)
• Éthique (2)
• Questions juridiques liées aux TIC (2)
• Respect de la vie privée (2)
• Accessibilité (1)

L’UX designer, autre nouvel entrant

Un autre profil rejoint la nomenclature : l’UX designer. Il a typiquement un bac +2/+3. Une spécialisation en design, ergonomie ou psychologie cognitive est parfois demandée. Il peut ensuite devenir lead UX, product designer, head of design, etc.

Le Cigref retient, comme KPI :

• Taux de conformité aux standards d’accessibilité (score d’audit RGAA)
• Taux de satisfaction des utilisateurs (satisfaction client, NPS, échelle d’évaluation de l’usabilité perçue**)
• Taux de parcours non terminés par l’utilisateur
• Taux de conversion avant/après optimisation, taux de succès des tâches, nombres d’erreurs utilisateur
• Productivité de la solution (temps mesuré sur un parcours)
• Score Ecoindex de l’interface, consommation énergétique moyenne par page, empreinte carbone estimée

Pour ce qui est des compétences :

• Expérience utilisateur (4)
• Identification des besoins (4)
• Stratégie et politique SI (4)
• Conception d’application (3)
• Test (3)
• Déploiement de solution (3)

Et des notions transversales :

• Utilisabilité (5)
• Accessibilité (5)
• Éthique (4)
• Questions juridiques liées aux TIC (4)
• Respect de la vie privée (4)
• Développement durable (3)
• Sécurité (1)

* En 2024, le Cigref avait aussi ajouté deux profils. D’une part, le data architect, qui reprenait les grandes lignes du profil de l’architecte d’entreprise… avec une forte coloration data. De l’autre, le product manager, découlant de l’augmentation des activités dévolues au product owner.

** Mesure la perception d’un produit ou d’un service selon le ressenti des utilisateurs, sur 3 axes : efficacité, efficience, satisfaction liée à l’interaction.

Illustration générée par IA

The post Le Cigref sort le Chief Digital Officer de sa nomenclature RH appeared first on Silicon.fr.

En 2027, l’ANSSI n’acceptera plus, en entrée de qualification, des produits de sécurité qui n’embarquent pas de cryptographie post-quantique.

Son directeur général Vincent Strubel l’a annoncé début octobre aux Assises de la sécurité. Sa déclaration a fait écho à une FAQ que l’agence avait publiée la veille, et où figurait cette même info.

En toile de fond, l’enrichissement du corpus de l’agence sur ce thème. Et, en parallèle, le franchissement de jalons. Entre autres, l’émission de ses premiers visas de sécurité pour des solutions comprenant de la cryptographie post-quantique. Plus précisément, des certifications CC (Critères Communs) pour la carte à puce MultiApp 5.2 Premium PQC de Thales (29 septembre) et pour le microcontrôleur S3SSE2A de Samsung (1^er octobre), qui exploitent le schéma de signature ML-DSA.

Les évaluations ont été conduites par le CEA-Leti, premier centre agréé « pour la portée PQC ». D’autres centres sont en cours d’agrément : Amossys (groupe Almond), EDSI (groupe NAGRA Kudelski), Quarkslab, Serma Safety & Security, Synacktiv et Thales/CNES.

Des guides et des référentiels à actualiser

Au-delà de l’horizon 2027, la FAQ mentionne l’échéance 2030. Avec un commentaire : à ce moment-là, il « ne sera plus raisonnable » d’acheter des produits qui n’intègrent pas de cryptographie post-quantique.

L’ANSSI invite à réaliser dès à présent un travail d’inventaire : identifier les données et les cas d’usage menacés, puis les équipements qu’il faudra mettre à jour, et prendre contact avec les fournisseurs pour connaître leur roadmap.

Pour le moment, l’agence focalise ses conseils essentiellement sur les offreurs. Dans cette logique, elle prévoit de publier des recommandations techniques (intégration dans les protocoles, crypto-agilité, formation de certificats…). Et aussi d’actualiser, en 2026, son référentiel IPsec DR afin d’y intégrer les algorithmes post-quantiques*. En attendant, elle invite à consulter un guide d’aide à la transition signé du renseignement néerlandais et de deux instituts de recherche nationaux (en anglais ; 2^e édition, décembre 2024).

L’ANSSI s’est aussi impliquée dans l’appel à projets « Développement de technologies innovantes critiques » du SGPI. La période de candidature a couru de novembre 2024 à avril 2025. Objectif : financer des briques technologiques en cybersécurité. Un des axes porte sur les outils d’aide à la transition post-quantique :

• Automatisation de l’inventaire des biens cryptographiques (sondes réseau, analyse d’applications / binaires, gestion du cycle de vie des certificats)
• Identification de biens vulnérables et priorisation des actions de migration
• Innovations dans les outils d’analyse de risque

D’autres mises à jour sont prévues à court terme, comme celle du guide de sélection des algorithmes de cryptographie (actualisation prévue cette année).

Dans l’UE, la perspective d’un « niveau minimal de préparation » pour fin 2026

Dans le corpus de l’agence, le « document fondateur » reste un avis sur la migration vers la cryptographie post-quantique, publié en 2022 (et mis à jour fin 2023). Y était déjà promue l’hybridation, à savoir la combinaison avec des algorithmes de cryptographie asymétrique pré-quantique à court et moyen terme pour éviter les régressions**.

L’ANSSI codirige par ailleurs, avec ses homologues allemand et néerlandais, le groupe de travail chargé d’élaborer la roadmap de l’UE « pour la mise en œuvre coordonnée de la transition vers la cryptographie post-quantique ».

En attendant le livrable final, un premier document a été publié en juin 2025. Il est censé contribuer à l’atteinte d’un niveau minimal de préparation dans les États membres pour fin 2026. Cela induit notamment l’identification et l’implication des parties prenantes. En la matière, la France est donnée comme exemple, pour les sondages que l’ANSSI a orchestrés auprès de trois populations (fournisseurs, utilisateurs, prestataires de conseil).

Il s’agira aussi d’avoir, pour fin 2026, engagé des pilotes en vue de la transition des cas d’usage à risque « intermédiaire » et « élevé ». Par « élevé », il faut par exemple entendre, pour des données protégées avec de la cryptographie à clé publique, les cas où une compromission de la confidentialité après 10 ans ou plus causerait encore des dommages significatifs.

Une transition espérée pour 2030 sur les cas d’usage à haut risque

La catégorisation des risques dépend plus globalement d’un score, calculé à partir d’un modèle décrit dans le guide néerlandais susmentionné. Trois facteurs l’influencent :

• Faiblesse de la cryptographie utilisée
• Impact estimé en cas de compromission
• Temps et effort nécessaires pour migrer vers le post-quantique (pour les éléments dont l’organisation responsable a le contrôle)

L’idée est que les cas d’usage à risque élevé aient migré en 2030 au plus tard (et qu’à ce même horizon, les mises à jour des logiciels et des firmwares utilisent des signatures résistantes). L’échéance 2035 est ciblée pour les cas d’usage à risque intermédiaire.

Cet agenda s’appuie en particulier sur une étude de l’ANSSI allemande (The status of quantum computer development ; dernière version publiée en janvier 2025). Il y est estimé qu’un ordinateur capable de casser la cryptographie actuelle pourrait être disponible d’ici à 2040.

Le document à l’adresse des États membres source un autre rapport, signé du Global Risk Institute. Et plus particulièrement une estimation : il y a 19 à 34 % de chances que sur la prochain décennie, un ordinateur quantique soit capable de casser RSA-2048 en 24 heures.

* Pour le moment, les produits quantum-safe ne peuvent être agréés DR s’ils doivent être conformes à un référentiel qui ne permet pas l’utilisation de tels algos.

** Les seuls algorithmes post-quantiques pour lesquels l’ANSSI ne recommande pas un recours systématique à l’hybridation sont les algorithmes de signature fondés sur le hachage : SLH-DSA, XMSS et LMS.

Illustration générée par IA

The post Transition post-quantique : l’agenda de l’ANSSI se remplit appeared first on Silicon.fr.

OpenAI adopte une approche prudente quant à l’usage d’Atlas en environnement d’entreprise.

Le groupe américain vient de lancer ce « navigateur IA » basé sur Chromium. Initialement pour les Mac Arm (Apple Silicon).

Atlas est accessible à tous les utilisateurs des abonnements ChatGPT « individuels » (Free, Plus, Pro, Go). Il l’est aussi avec les offres ChatGPT Business, Enterprise et Edu… mais en bêta. Et avec des limites qu’OpenAI énumère ouvertement.

Atlas manque encore d’une config entreprise

Parmi ces limites, il y a l’absence de garanties de résidence des données. Il n’y a pas non plus, dans l’optique de déploiements gérés, de canal de distribution spécifique, ni d’épinglage de versions.

Atlas n’entre pour le moment pas dans le périmètre des certifications SOC 2 et ISO d’OpenAI. Il n’émet par ailleurs pas de logs vers la Compliance API et n’est pas doté d’intégrations SIEM ou eDiscovery.

Certains types de données peuvent ne pas être couverts par les engagements d’isolation et de conservation associés à l’abonnement Enterprise, nous précise-t-on. Les données de navigation en fait partie. Comme celles relatives à l’activité agentique.

Sur la partie réseau, Atlas ne permet pas de définir des listes blanches d’adresses IP, ni de paramétrer le private ingress. Il n’a plus globalement pas d’allowlists et de blocklists spécifiques, ni d’ailleurs ses propres RBAC, SSO et provisionnement SCIM.

Six clés MDM sont officiellement prises en charge pour commencer :

• CookiesAllowedForUrls (liste des sites autorisés à définir des cookies)
• ExtensionInstallAllowList (liste d’extensions autorisées)
• ExtensionInstallBlockList (liste d’extensions bloquées)
• ExtensionInstallForceList (liste d’extensions obligatoirement installées)
• ExtensionSettings (paramétrage des extensions)
• RemoteDebuggingAllowed (autorisation du débogage distant)

Beaucoup d’autres clés type Chromium devraient fonctionner. Le support officiel sera étendu quand Atlas passera en disponibilité générale sur ChatGPT Business, Enterprise et Edu.

Windows a Recall, Atlas a les « souvenirs »

Sur les abonnements Business, le navigateur est disponible par défaut dans tous les espaces de travail. Sur les abonnements Enterprise, un admin doit l’activer au préalable.

Dans l’un et l’autre cas, conformément à la politique appliquée à ChatGPT, les données de navigation ne sont pas exploitées pour entraîner les modèles d’OpenAI* (elles peuvent l’être sur les abonnements individuels ; c’est toutefois en opt-in).

Autre élément en opt-in : la mémoire. Cette fonctionnalité, diffusée sur ChatGPT à partir de septembre 2024, consiste à retenir des éléments-clés des conversations pour ensuite améliorer les résultats. OpenAI l’avait déclinée au printemps 2025 pour aider à personnaliser les résultats de recherches web.

La voilà désormais intégrée dans Atlas. Elle implique la transmission du contenu web consulté vers les serveurs d’OpenAI, où ce contenu est synthétisé, puis retransmis à Atlas pour mettre à jour ses « souvenirs ».

Les contenus web sont supprimés du serveur dès qu’ils ont été synthétisés. Les résumés le sont sous 7 jours. Les utilisateurs de macOS 26 ont la possibilité d’opter pour un traitement intégralement en local. Les « souvenirs » en eux-mêmes ne se suppriment pas, mais ils évoluent en fonction de l’historique effacé. Il est également possible de les archiver pour ne plus que ChatGPT y accède.

Atlas permet aussi de rendre des pages web « invisibles » pour ChatGPT. Cela se règle dans les paramètres ou via l’icône cadenas dans la barre d’adresse.

* Pour ce qui est de l’exploitation des conversations, notamment dans la barre latérale d’Atlas (fonction Ask ChatGPT), ce sont les paramètres de ChatGPT qui ont la priorité.

Illustration générée par IA

The post Avec Atlas, OpenAI avance à tâtons sur le B2B appeared first on Silicon.fr.

Une région cloud vous manque est tout est dépeuplé…

L’image est probablement exagérée, mais elle illustre le niveau de centralisation qui demeure chez AWS. Sa principale région (us-east-1, qui est aussi la plus ancienne) apparaît comme un point faible, ne serait-ce que par le nombre de services qui y ont leur plan de contrôle. On a pu le mesurer cette semaine avec un incident au retentissement mondial parti d’un problème de DNS interne.

Cet incident n’est pas, et de loin, le premier à avoir eu comme épicentre la région us-east-1. En témoigne, en particulier, une liste publique de post-mortem qu’AWS a consacrés aux problèmes qu’il considère avoir eu « un impact clent significatif ».

Avril 2011 : EBS part en boucle infinie

EC2 a connu des perturbations dues essentiellement au dysfonctionnement d’un sous-ensemble de volumes EBS dans une AZ. Ils n’acceptaient plus les opérations de lecture et d’écriture.

À l’origine, il y a une modification destinée à augmenter la capacité du réseau primaire – celui qui porte la communication entre les nœuds EBS, les instances EC2 et le plan de contrôle.

La redirection du trafic a été mal exécutée. Au lieu de basculer vers un routeur secondaire sur ce même réseau, tout a été acheminé sur le réseau secondaire, dédié à la réplication et dont les capacités étaient plus faibles. De sorte qu’il a saturé.

Certains nœuds se sont ainsi retrouvés privés des deux réseaux et ont perdu le lien avec leurs répliques. Dès la reconnexion, ils ont enclenché massivement un re-mirrorring, dépassant rapidement les capacités du cluster et entrant par là même dans une boucle infinie.

Le cluster ne pouvait plus répondre aux requêtes API visant à créer des volumes. Or, puisque cette API avait un long timeout, les appels se sont accumulés jusqu’à épuiser les threads alloués au plan de contrôle. Lequel a fini par devoir basculer les traitements vers une autre AZ.

À cela s’est ajoutée une condition de concurrence dans le code des nœuds EBS. Elle favorisait les échecs lors de la fermeture simultanée d’un grand nombre de requêtes de réplication.

Dans ce contexte, le volume de négociations entre instances EC2 et nœuds EBS pour s’entendre sur la copie principale a explosé, pesant d’autant plus sur le plan de contrôle.

Juin 2012 : EC2, EBS, ELB et RDS secoués par un orage

À la suite d’une surtension causée par un orage, deux datacenters soutenant une même AZ basculent sur les groupes électrogènes. La procédure échoue toutefois sur l’un d’entre eux, faute d’une stabilisation de la tension. Les serveurs passent alors sur onduleur… jusqu’à épuisement de la réserve énergétique. La séquence se produit à deux reprises, l’alimentation ayant été brièvement rétablie.

Le datacenter problématique n’hébergeait qu’une petite partie des ressources de la région (environ 7 % des instances EC2, par exemple). Mais l’impact a été fort pour certains clients. Sur deux plans. D’un côté, l’indisponibilité d’instances et de volumes (limitée à l’AZ touchée). De l’autre, la dégradation de l’accès aux plans de contrôle (sur toute la région east-us-1).

Le délai de rétablissement d’EC2 a été allongé par un goulet d’étranglement au niveau du démarrage des serveurs. Il l’a aussi été pour EBS, vu l’incapacité à basculer rapidement vers un nouveau datastore primaire.

L’offre ELB a aussi été perturbée. L’alimentation revenue, un bug est survenu : le plan de contrôle a tenté de scaler les instances sous-jacentes. Le flux de requêtes qui en a résulté a occasionné une surcharge. Couplé aux requêtes d’association des nouvelles instances EC2 que créaient les clients, il a saturé le plan de contrôle, d’autant plus que celui-ci utilisait une file d’attente partagée pour toute la région.

RDS a été nettement tributaire de la récupération d’EBS. Il a aussi fallu faire avec un bug logiciel qui a empêché le failover sur certaines configurations multi-AZ.

Octobre 2012 : l’agent de collecte EBS frappe à la mauvaise adresse

Des nœuds EBS ont rencontré des problèmes dans une AZ. La cause : un bug dans l’agent collectant des données à des fins de maintenance.

La semaine précédente, un des serveurs destinés à héberger ces données avait été remplacé après une panne matérielle. Dans ce cadre, l’enregistrement DNS avait été actualisé. La mise à jour ne s’était néanmoins pas propagée correctement. Certaines instances de l’agent continuaient donc à tenter de joindre l’ancienne adresse.

Le service de collecte étant tolérant aux manques de données, le problème n’avait pas été immédiatement visible. Jusqu’à ce que l’agent en arrive à saturer la mémoire des serveurs à force de répéter les tentatives de connexion. À tel point que les serveurs EBS ne pouvaient plus répondre aux requêtes clients. Pour ne rien arranger, beaucoup étant tombés au même moment, il n’y en avait pas assez de rechange.

L’incident a entraîné des difficultés pour utiliser les API de gestion. A fortiori parce que la politique de plafonnement de débit mise en place par AWS pour assurer la stabilité lors de la phase de récupération était trop agressive.

Juin 2014 : SimpleDB (quasiment) injoignable

Pendant deux heures, presque aucun appel API vers ce datastore distribué n’a abouti. Il a ensuite fallu du temps supplémentaire pour que tout revienne à la normale, notamment sur la création et la suppression de domaines.

Le déclencheur fut une coupure de courant. Plusieurs nœuds de stockage étaient devenus indisponibles. Lorsqu’ils ont redémarré, la charge s’est accrue sur le service de verrouillage interne de SimpleDB.

Ce service sert à déterminer quel ensemble de nœuds est responsable d’un domaine donné. Chaque nœud le contacte régulièrement pour vérifier qu’il a toujours les responsabilités qu’il pense avoir.

Avec l’augmentation de la charge, la latence s’est accrue et les nœuds ne pouvaient pas finaliser le handshake avant le timeout. Ils finissaient ainsi par s’auto-éjecter du cluster. Ils ne pouvaient alors le rejoindre qu’en recevant une autorisant de la part des nœuds de métadonnées… qui étaient malheureusement eux-mêmes indisponibles.

Septembre 2015 : DynamoDB dépassé par ses index secondaires globaux

En septembre 2015, les index secondaires globaux (GSI, global secondary index) sont encore relativement nouveaux sur DynamoDB. Ils permettent d’accéder aux tables via des clés alternatives.

Les tables DynamoDB, rappelons-le, sont partitionnées et distribuées entre serveurs. L’attribution d’un groupe de partitions à un serveur est alors dite membership. Elle est gérée par un service de métadonnées interne auprès duquel les serveurs de stockage doivent périodiquement se renseigner. C’est le cas après une coupure réseau.

Il en est justement intervenu une. Sauf qu’à la relance, une partie des réponses du service de métadonnées a dépassé les délais de transmission autorisés. En conséquence de quoi les serveurs de données concernés ont arrêté d’accepter des requêtes.

L’adoption des GSI a pesé lourd. Ces derniers ont en effet leur propre ensemble de partitions. Ils contribuent ainsi à augmenter la taille des infos de membership. C’est ainsi que le temps de traitement de certaines a fini par dépasser les délais. Le phénomène a été accentué du fait de la sollicitation simultanée par un grand nombre de serveurs de données. Lesquels ont réitéré leurs requêtes, maintenant donc une charge élevée.

AWS a dû se résoudre à mettre la communication en pause pour pouvoir ajouter de la capacité (la charge continue l’empêchait d’effectuer ses requêtes administratives).

SQS, qui utilise une table DynamoDB interne décrivant les files d’attente, a été affecté, faute de pouvoir rafraîchir correctement son cache. Les erreurs API se sont par ailleurs multipliées sur l’autoscaling EC2, qui exploite lui aussi DynamoDB (stockage des infos sur les groupes et de configs de lancement). CloudWatch n’a pas été épargné, entre autres sur la partie métriques.

Février 2017 : S3 planté par une erreur de débogage

Au début, il y a une opération de débogage d’un problème qui causait des lenteurs sur le système de facturation de S3.

Une commande était censée retirer quelques serveurs d’un sous-système. Mais une entrée incorrecte en a retiré davantage, et liés à deux autres sous-systèmes. L’un, dit d’index, gérait les métadonnées et les infos d’emplacement de tous les objets S3 dans la région us-east-1. L’autre, dit de placement, permettait l’allocation de nouveaux espaces de stockage.

Il a fallu relancer les deux, qui ne l’avaient pas été depuis des années. Le processus de vérification d’intégrité a ainsi pris plus longtemps que prévu.

Pendant le redémarrage, S3 ne pouvait pas répondre aux requêtes. D’autres services ont été impactés dans la région pendant l’indisponibilité de ses API. Parmi eux, le lancement de nouvelle instances EC2 et la création de volumes EBS à partir de snapshots.

Novembre 2020 : Kinesis atteint son plafond de threads

Le déclencheur fut l’ajout de capacité sur le front-end.

Cette flotte de serveurs gère le routage vers le back-end. Elle assure pour cela l’authentification et le contrôle des débits ; tout en maintenant des informations de membership (shard-map), dont chaque serveur stocke une copie.

Ces infos sont obtenues par appel à un microservice et par récupération de données dans une table DynamoDB. Mais aussi par le traitement continu des messages des autres serveurs du front-end, un thread étant dédié à chacun.

Les nombreuses erreurs constatées se sont avérées ne pas toutes découler de l’ajout de capacité. La principale en résultait, néanmoins. La cause racine : le dépassement, sur tous les serveurs du front-end, du nombre maximal de threads autorisé par une configuration OS. Les caches n’étaient donc plus construits et les shard-maps devenaient obsolètes, ne permettant plus de diriger les requêtes.

Pour des raisons de concurrence, il n’a été possible de relaner que quelques centaines de serveurs par heure, alors que la flotte en comptait des milliers. Il existait effectivement une situation de compétition entre les ressources utilisées pour peupler le shard-map et celles utilisées pour traiter les requêtes entrantes. Une remise en ligne trop rapide aurait entraîné un risque de conflits et donc d’erreurs.

Parmi les services impactés, Cognito, qui exploite Kinesis Data Streams pour collecter et analyser les patterns d’accès aux API. Ou CloudWatch, qui s’en sert pour traiter logs et métriques… et qui a aussi eu un effet en cascade sur Lambda (l’invocation de fonctions supposait alors la publication de métriques vers CloudWatch).

Décembre 2021 : de la friture sur le réseau

AWS utilise un réseau interne pour héberger des services fondamentaux de type monitoring, DNS, autorisation… et une partie du plan de contrôle EC2. Des passerelles permettent de communiquer avec le réseau principal, où fonctionnent la majorité des services de la branche cloud d’Amazon ainsi que les applications des clients.

La mise à l’échelle automatique d’un service sur le réseau principal a déclenché de l’agitation sur le réseau interne. Un pic de connexions a surchargé les passerelles, accroissant latence et erreurs. Les tentatives répétées de connexion ont favorisé une congestion.

Cette congestion a limité les capacités de supervision et donc de résolution du problème. La redirection du trafic DNS a aidé, mais n’a pas tout résolu. Le délai s’est allongé d’autant plus que les systèmes internes de déploiement d’AWS étaient eux aussi touchés.

Parmi les services affectés ont figuré les API EC2 destinées à lancer et à décrire des instances. Et donc, par rebond, des services comme RDS, EMR et WorkSpaces.
Les API Route 53 ont aussi subi le choc (pas possible de modifier des enregistrements). Sur STS, la latence s’est accrue pour la communication d’authentifiants aux fournisseurs d’identité tiers. L’accès aux buckets S3 et aux tables DynamoDB via des endpoints VPC a également été perturbé.

Juin 2023 : le front-end Lambda en surcapacité

Lambda est architecturé en cellules composées de sous-systèmes. Sur chacune, le front-end réceptionne les invocations et en assure le routage, tandis qu’un gestionnaire met à disposition un environnement d’exécution.

Un jour de juin 2023, le front-end a scalé pour absorber un pic de trafic… et a atteint, dans une cellule, un palier de capacité « jamais vu auparavant ». Assez pour entraîner un problème logiciel : les environnements d’exécution alloués n’étaient pas complètement utilisés par le front-end. Les invocations produisaient ainsi davantage d’erreurs.

L’incident a impacté la console AWS dans la région us-east-1. Il a aussi touché STS (taux d’erreurs sur la fédération SAML, notamment), EKS (provisionnement de clusters) et EventBridge (jusqu’à 801 secondes de latence pour le routage vers Lambda).

Juillet 2024 : Kinesis perturbé par un profil de workload

Problème également dans une cellule pour Kinesis Data Streams. Plus précisément, une cellule utilisée exclusivement par les services AWS (par opposition à celles dédiées aux clients).

En toile de fond, une mise à niveau d’architecture, avec un nouveau système de gestion. Celui-ci n’a malheureusement pas réussi à gérer le profil de workload spécifique de la cellule en question (un très grand nombre de shards à très bas débit).

Ces shards n’ont pas été bien répartis entre les hôtes. Les quelques-uns qui ont hérité des « gros morceaux » se sont mis à transmettre des messages de statut volumineux qui n’ont pas pu être traités dans les délais autorisés. Le système de gestion, pensant avoir affaire à des nœuds défectueux, a commencé à redistribuer les shards. D’où un pic d’activité qui a surchargé un autre composant, utilisé pour établir des connexions sécurisées vers les sous-système du plan de données. Le traitement du trafic Kinesis s’en est trouvé affecté.

Parmi les services touchés, CloudWatch Logs (utilisant Kinesis comme tampon), la livraison d’événements dans S3, ainsi que l’invocation des API PutRecord et PutRecordBatch avec Data Firehose. Des effets en cascade ont été recensés sur ECS, Lambda, Glue ou encore Redshift.

Illustration générée par IA

The post Panne AWS : 10 incidents dont la région us-east-1 fut l’épicentre appeared first on Silicon.fr.

Perplexity, Signal, Snapchat, Uber, le site Internet du fisc britannique… Quantité de services numériques ont connu, ce 19 octobre, des perturbations liées à un incident chez AWS.

Pas de bilan officiel pour l’heure, mais le dernier message sur la page de statut AWS donne une bonne idée de l’enchaînement des événements.

Il est environ 9 heures du matin en France quand les problèmes commencent. Les erreurs et la latence s’accroissent dans la région us-east-1. La conséquence d’un souci de résolution DNS au niveau des points de terminaison DynamoDB.

Vers 11 h 30, le fonctionnement est rétabli. Mais des désagréments persistent dans des briques dépendantes de DynamoDB. Par exemple, le sous-système qui lance les instances EC2.
AWS constate aussi des problèmes d’équilibrage de charge qui déteignent sur des services comme CloudWatch et Lambda. Ils sont définitivement éliminés vers 18 h30 après avoir plafonné temporairement des opérations telles que le traitement des files d’attente SQS.

Vers minuit, tout était revenu à la normale, selon le groupe américain. Avec cependant un backlog à écouler sur des services comme AWS Config, AWS Connect et Amazon Redshift.

Plusieurs niveaux de dépendance à la région us-east-1

AWS reconnaît – sans toutefois s’y attarder – que l’incident a impacté des services non localisés dans la région us-east-1, mais qui en dépendent. Il mentionne notamment l’IAM.

Ce dernier fait partie, dans sa nomenclature, des « services globaux uniques par partition« . Globaux, parce que leurs plans de contrôle et de données n’existent pas indépendamment dans chaque région. Leurs ressources sont « mondiales », en tout cas à l’échelle de leur partition AWS (ici, le cloud public/commercial, par opposition à celles dédiées à la Chine ou au gouvernement américain).

Pour la plupart de ces services, le plan de données est distribué, tandis que le plan de contrôle est hébergé dans une seule région AWS. Il se trouve ainsi dans la région us-east-1 pour l’IAM, comme pour AWS Organizations et Account Management (gestion des comptes cloud), ainsi que le DNS privé Route 53. Son indisponibilité est donc susceptible de compromettre les opérations CRUDL (create, read, update, delete, list) à l’échelle globale.

Les « services globaux en périphérie » ont eux aussi un plan de contrôle monorégion (leur plan de données étant distribué entre points de présence, et potentiellement aussi entre régions). Cette catégorie comprend, entre autres, le DNS public Route 53, AWS Shield Advanced (anti-DDoS) et le CDN CloudFront (ainsi que son WAF et son gestionnaire de contrôle d’accès).

Il existe aussi des services régionaux ou zonaux dépendants d’autres régions. Sur Amazon S3, par exemple, diverses opérations (tagging, réplication, monitoring, ACL…) passent par la région us-east-1. Dans cett même région se trouve doans le plan de contrôle Route 53, sollicité pour créer des enregistrements DNS lors du provisionnement de ressources sur un éventail de services : PrivateLink (endpoints VPC), API Gateway (API REST et HTTP), ELB (répartiteurs de charge), OpenSearch Service (domaines), ECS (découverte de services), etc.

Il y a également des services qui utilisent des endpoints globaux par défaut. Illustration avec STS (Security Token Service, qui génère des jetons d’authentification éphémères). Exploité dans le SDK ou le CLI AWS, il utilise par défaut la région us-east-1. Autres exemples : IAM Identity Center et S3 Storage Lens. Le premier utilise par défaut l’endpoint SAML global hébergé sur us-east-1. Avec le second, la configuration du dashboard et les métriques associées sont, en standard, stockées dans cette même région.

La région des nouveautés… et des tutos

Localisée en Virginie, sur le campus d’Ashburn, la région us-east-1 réunit, au dernier pointage, 159 datacenters. Elle est d’autant plus structurante pour le cloud AWS qu’elle en a été la base : c’est avec elle que tout a commencé, en 2006 (lancement de S3).

Parallèlement à son ancienneté, us-east-1 accueille plus de charges de travail que toute autre région AWS. Ce qui contribue d’autant plus à en faire, de manière générale, un point de défaillance potentiel.

Son attrait peut s’expliquer par une tarification historiquement plus basse, quoique l’écart avec les autres régions s’est réduit au fil du temps. Elle a aussi la particularité d’être, aujourd’hui encore, souvent la première à accueillir les nouveaux services AWS. Beaucoup de tutos et d’articles la mettent par ailleurs en avant et elle est la valeur par défaut dans nombre d’outils.

Les frais de réseau peuvent de surcroit s’avérer dissuasifs pour qui voudrait mettre en place une redondance multirégions. Même si AWS a fait évoluer en partie sa politique, en particulier pour peupler sa région us-east-2 (prix ramené au niveau de celui du trafic interzones).

La centralisation des plans de contrôle peut se justifier lorsqu’une cohérence immédiate est nécessaire, comme pour l’authentification ou la facturation. Une décentralisation aurait plus globalement un coût non négligeable pour AWS, tout en compromettant éventuellement les engagements de disponibilité.

Illustration © blackboard – Adobe Stock

The post Panne AWS : la région us-east-1, point faible connu mais persistant appeared first on Silicon.fr.

À l’instar de la réutilisation de chaleur lorsque surviennent des épisodes caniculaires ou de stress hydrique, des externalités positives peuvent devenir des contraintes.

Cette remarque figure dans l’AFNOR SPEC 2314. Publié en juin 2024 et mis à jour pour la dernière fois en avril 2025, le document ne constitue pas une norme. Il vise à fournir un catalogue de méthodes et de pratiques à appliquer pour tendre vers une IA « frugale ». Une soixantaine d’organismes (47 du secteur privé, 7 du secteur public, 6 de la sphère académique/recherche) y ont contribué.

Les 31 bonnes pratiques référencées sont classées sur deux axes. D’un côté, en fonction des segments « service », « données » et « infrastructures ». De l’autre, selon les étapes du cycle de vie d’une IA.

Six de ces bonnes pratiques ont la particularité de nécessiter un effort important tout en présentant un faible gain*. Les voici.

Faire évoluer les stratégies de mesure d’impact en fonction des enjeux et des contraintes

C’est sur ce point qu’est évoquée la question des externalités positives devenant contraintes. Une manière d’avaliser cette bonne pratique qui consiste à réévaluer les stratégies de mesure d’impact et les critères de frugalité tout au long du cycle de vie d’un service d’IA.

Cette réévaluation, qu’on assurera régulièrement et plusieurs fois par an, pourra impliquer l’évolution et la rationalisation des outils de mesure.

Mettre en place un référentiel unique de « services IA » frugaux

Ce référentiel devra comprendre au minimum, pour chaque service :

• Un identifiant unique
• Son statut de déploiement
• L’identification de l’équipe en charge de sa gestion
• La description des modèles sous-jacents
• Des éléments sur les données et l’infra, éventuellement tirées d’une base de données existante

L’AFNOR SPEC 2314 recommande de créer, dans ce référentiel, un espace spécifique d’analyse de la frugalité. Et d’ajouter, pour chaque service, deux critères déclaratifs. L’un relatif au statut de l’évaluation (non étudié, en cours, étudié, audité…). L’autre, à l’existence d’une procédure de réutilisation et d’évolution du service. Dans l’idéal, on complétera par des infos plus détaillées décrivant chaque indicateur de frugalité par service.

Avoir une offre de produits numériques IA sur étagère

Cette bonne pratique évite les doublons tout en facilitant l’amélioration de l’existant et l’élimination des produits devenus obsolètes. Elle suppose de favoriser la réutilisation de tout service voire système d’IA, avec un processus de mise en œuvre simplifiée (intégration sans développement de fonctionnalités supplémentaires). Mais aussi de permettre de participer à l’évolution fonctionnelle d’un produit sans changer la manière de l’utiliser. Dans cette perspective, on s’assurera que le demandeur peut :

• Accéder facilement au backlog
• Accéder à la procédure de gestion d’une nouvelle demande (mise à jour ou évolution)
• Afficher les règles de priorisation pour toute demande

Le demandeur doit pouvoir développer et/ou intégrer le service par lui-même ou bien sous-traiter la démarche. À la fin de chaque création de service d’IA, on mettra à disposition une procédure de réutilisation et de mise à jour.

Favoriser les terminaux utilisateurs pour l’entraînement ou l’inférence

Principe général à suivre : identifier des petits modèles, mettre en place des techniques d’optimisation et de compression (autre bonne pratique de la SPEC AFNOR 2314), évaluer les impacts de cette approche et l’intégrer dans les réponses possibles au besoin.

Écrire du code pouvant être amélioré par plusieurs personnes et réimplémenté sur plusieurs environnements

Il s’agit ici de produire du code réutilisable pour réentraîner facilement le modèle ou pouvoir exploiter des modules dans d’autres projets.

Pour limiter l’empreinte environnement sont conseillés des langages compilés (C, C++ et CUDA sont cités). Ou bien, pour les langages de plus haut niveau, un interpréteur optimisé (exemple : Pythran ou Numba pour Python).

Si cela est possible dans la limite des compétences en développement des data scientists et des choix stratégiques de la sociétés, on favorisera C pour développer l’IA avec la norme ANSI C99 en utilisant des bibliothèques standards.

On cherchera plus globalement à pérenniser le code en utilisant au maximum les bibliothèques courantes, en privilégiant les langages multienvironnements et en vérifiant les licences d’utilisation (risque de portabilité et de surcoût dans le temps).

Décomposer un gros modèle d’IA en plusieurs petits modèles

La somme de l’empreinte de petits modèles spécialisés sera inférieure à l’empreinte d’un gros modèle généraliste, postule l’AFNOR SPEC 2314.

Cette décomposition permet, de plus, une mutualisation des modèles. Et favorise la réduction de l’empreinte du réentraînement – comme de l’inférence. Elle suppose un niveau de compétence suffisant pour la mise en œuvre de modèles multiples – éventuellement à l’appui d’un orchestrateur.

* Elles sont plus précisément dans le top 10 des bonnes pratiques présentant le plus faible gain et dans le top 10 de celles nécessitant le plus d’effort.

Illustration générée par IA

The post IA frugale : 6 bonnes pratiques « secondaires » du référentiel AFNOR appeared first on Silicon.fr.

Un format simple pour un concept simple : ainsi Anthropic présente-t-il Claude Skills.

Il ne s’agit pas tant d’une fonctionnalité – le groupe américain évite d’ailleurs ce terme – que d’une façon spécifique d’apporter du contexte. En l’occurrence, par l’intermédiaire de fichiers Markdown et d’éventuelles ressources associées (code, templates, documentation, etc.).

Le fichier en question (SKILL.md) contient un en-tête YAML donnant le nom et la description de la skill. Cette approche ouvre la voie à ce qu’Anthropic appelle une « divulgation progressive », de sorte que Claude ne surcharge pas sa fenêtre de contexte.

Le modèle n’accède effectivement pas tout de suite aux skills. Il intègre d’abord leur nom et leur description dans son prompt système, puis les enclenche ou non en fonction des tâches qu’il a à accomplir.

Dans le prolongement d’AGENTS.md

Claude Skills s’inscrit dans la lignée d’AGENTS.md, un « readme pour agents de codage » qui a émergé sous l’impulsion de Google, Cursor et OpenAI, entre autres. Il y ajoute néanmoins une forme de structure arborescente, SKILL.md pouvant faire appel à d’autres fichiers Markdown situés dans le même dossier.

Si le mécanisme apparaît reproductible chez d’autres fournisseurs, son implémentation actuelle est dépendante de l’écosystème Anthropic. Elle utilise notamment l’outil Bash pour la lecture des fichiers Markdown et pour l’éventuelle exécution de scripts associés.

Tout skill enclenchée entre dans la fenêtre de contexte de Claude (ordre de grandeur : jusqu’à 5000 tokens, selon Anthropic, le nom et la description consommant quant à eux environ 100 tokens).

Trouver la complémentarité avec MCP

Le système est à l’œuvre depuis quelques semaines sur Claude.ai, portant la fonctionnalité de création de documents (Word, Excel, PowerPoint, PDF). Il est accessible sur les forfaits Pro, Max, Team et Enterprise. Un concepteur est disponible pour créer des skills… à l’aide de ce même Claude. On peut ensuite les importer au format .zip via les paramètres. Elles sont propres à chaque utilisateur.

L’usage de Claude Skills sur l’API Messages exige trois en-têtes : skills-2025-10-02 (active de la fonctionnalité), code-execution-2025-08-25 (permet aux skills de fonctionner dans l’exécuteur de code) et files-api-2025-04-04 (active les téléchargements et téléversements de fichiers).
Les skills sont à uploader via l’endpoint /v1/skills. Elles sont accessibles à toute l’organisation. Pour y faire appel, on les intègre dans le paramètre container en précisant leur identifiant, leur type et éventuellement leur version. On peut en inclure jusqu’à 8 par requête.

Les skills sont aussi disponibles avec Claude Code, y compris sous forme de plug-in. Elles peuvent être personnelles ou partagées.

Anthropic dit réfléchir à la complémentarité avec MCP, pour « apprendre aux agents des workflows plus complexes impliquant des outils externes ». Il caresse aussi l’idée que ces agents puissent un jour créer leurs propres skills de manière autonome.

Illustration générée par IA

The post Claude Skills, game changer pour les LLM ? appeared first on Silicon.fr.

Tarification élevée chez certains fournisseurs, complexe chez d’autres… si ce n’est les deux à la fois : au fil des ans, ce constat d’ensemble s’est imposé dans le Magic Quadrant de la sécurité applicative.

La dernière édition n’y déroge pas. En particulier chez les « leaders ». Ils sont 4 sur 6 à faire l’objet d’un avertissement quant à leur pricing :  Black Duck, Checkmark, HCLSoftware et OpenText.

Gartner avait déjà épinglé Checkmarx et OpenText sur ce point dans l’édition précédente. C’était en mai 2023. Le cabinet américain avait fait de même avec un autre « leader » d’alors : Synopsys. Si ce dernier a disparu des tablettes, c’est qu’il a, depuis, vendu son activité de sécurité applicative (AST, application security testing) à Clearlake Capital et Francisco Partners. Il en est né Black Duck, qui a repris la propriété intellectuelle, la clientèle, l’équipe de direction et les équipes commerciales.

D’une édition à l’autre de ce Magic Quadrant, les critères d’inclusion sur le plan fonctionnel ont peu évolué. Comme en 2023, sur l’identification de vulnérabilités, seuls le SAST (analyse statique) et le SCA (analyse de composition logicielle) ont été jugés indispensables. Le DAST (analyse dynamique) et le IAST (analyse interactive) sont restés facultatifs. Idem, entre autres, pour l’analyse des conteneurs, des API et de l’IaC.
Concernant la gestion de la posture de sécurité des applications, la jonction avec des outils tiers n’était pas obligatoire. Même chose, sur la partie supply chain logicielle, pour la gestion des pipelines de développement et des systèmes sous-jacents (seule la gestion du cycle de vie des SBOM était obligatoire).

Sur l’axe « exécution », traduisant la capacité à répondre à la demande du marché, les 16 fournisseurs classés se positionnent ainsi :

Rang	Fournisseur	Évolution
1	Black Duck	=
2	Checkmarx	+ 2
3	Veracode	– 1
4	Snyk	+ 3
5	OpenText	=
6	GitHub	+ 2
7	GitLab	– 4
8	HCLSoftware	– 2
9	Data Theorem	nouvel entrant
10	JFrog	nouvel entrant
11	Sonatype	=
12	Contrast Security	– 3
13	Semgrep	nouvel entrant
14	Mend.io	– 2
15	Cycode	nouvel entrant
16	Apiiro	nouvel entrant

Sur l’axe « vision », reflétant les stratégies (sectorielle, géographique, commerciale/marketing, produit…) :

Rang	Fournisseur	Évolution
1	Checkmarx	+ 3
2	HCLSoftware	+ 7
3	Snyk	+ 4
4	Black Duck	– 3
5	OpenText	– 3
6	Sonatype	+ 5
7	Contrast Security	– 4
8	Mend.io	– 2
9	Veracode	– 4
10	JFrog	nouvel entrant
11	GitLab	– 3
12	Semgrep	nouvel entrant
13	Cycode	nouvel entrant
14	GitHub	– 4
15	Apiiro	nouvel entrant
16	Data Theorem	nouvel entrant

Hormis Synopsis pour les raisons sus-exposées, un fournisseur est sorti du Magic Quadrant : Onapsis, faute d’une prise en charge suffisamment exhaustive des langages de programmation.

Black Duck peut progresser sur la sécurité de la supply chain logicielle

Black Duck se distingue positivement sur la sécurité du code, avec son plug-in Code Sight pour les IDE (SAST et SCA), récemment doté d’un assistant IA. Bon point également sur la gestion de la posture de sécurité des applications (vue exhaustive du risque, gestion de la conformité, ingestion depuis des outils tiers). Ainsi que pour l’analyse de binaires, qui peut se révéler plus précise que les méthodes de détection basées sur les manifestes.

Le marché perçoit comme complexe la tarification de Black Duck. Son offre peut par ailleurs se révéler coûteuse pour les PME (moins de 1000 employés dans la nomenclature de Gartner) qui ne recherchent que du SCA ou du SAST. Il existe aussi une marge de progression sur la sécurité de la supply chain logicielle (prise en charge limitée de la détection des configurations de pipelines non sécurisées et de la validation d’intégrité des artefacts, notamment).

Checkmarx, limité sur la sécurité des composants IA

Checkmark se distingue lui aussi sur la gestion de la posture de sécurité des applications (vue unifiée, corrélation avec les outils tiers). Gartner apprécie aussi l’assistance apportée aux développeurs par l’intermédiaire du SAST AI Security Champion, qui automatise la remédiation au sein des IDE. Il salue également les possibilités sur le volet de la supply chain logicielle (traitement des packages open source, en particulier, ainsi que l’identification des erreurs de configuration dans les dépôts de code).

L’offre de Checkmarx manque toutefois d’une brique IAST et ne couvre pas non plus l’analyse du code binaire des applications mobiles. De plus, la détection des risques sur l’IA est limitée aux vulnérabilités dans les bibliothèques utilisées pour développer ou intégrer des LLM (elle ne couvre pas l’injection de prompts ou la divulgation de données sensibles). Quant à la tarification, elle peut s’avérer difficile à comprendre, comme le packaging des offres, jusqu’aux options de support.

Faiblesses sur le support chez HCLSoftware

HCLSoftware se distingue par ses avancées sur la gestion de la posture de sécurité des applications (amélioration des dashboards, de la corrélation, du reporting et de la gestion de la supply chain logicielle via un partenariat avec OX Security). Autre point fort : ses moteurs d’analytics, utilisés pour réduire les faux positifs et étendre la détection, entre autres pour la compréhension dynamique des API. La sécurité des API, justement, est jugée robuste.

HCLSoftware a tardé à rendre certains éléments disponibles sur site (SCA et sécurité des conteneurs ne sont déployables dans ce mode que depuis septembre 2025). Son offre est par ailleurs limitée pour ce qui est de la détection des logiques métier au niveau des API (des outils tiers sont souvent nécessaires). Le prix peut se révéler prohibitif pour les petites équipes, tandis que le support peut manquer d’exhaustivité dans certaines régions géographiques.

OpenText peut mieux faire sur la remédiation automatisée

OpenText se distingue lui aussi positivement sur la gestion de la posture de sécurité des applications. Il en va de même sur la gestion des risques pour les composants et services IA (détection des injections de prompts, de la divulgation d’informations sensibles, et gestion des inputs non sécurisés). Gartner apprécie aussi la variété des options de déploiement (on-prem, SaaS, cloud privé, managé), doublée d’un support linguistique exhaustif.

Une brique native pour le test de sécurité des conteneurs fait défaut. Il manque aussi la détection des erreurs de configuration dans les pipelines de développement et les systèmes de gestion de code source. Gartner souligne également les limites de la remédiation automatisée (prise en charge variable des langages de programmation dans les IDE, absence de détection des breaking changes au niveau des PR). S’y ajoute une tarification complexe, liée autant à la diversité des options de déploiement qu’à l’ancienneté d’OpenText sur ce marché.

Chez Snyk, attention au focus sur les langages modernes

Au contraire d’OpenText, Snyk se distingue positivement sur la remédiation assistée par IA, qui englobe SAST, SCA, IaC et conteneurs à travers IDE, PR, UI web et CLI. Gartner apprécie plus globalement la qualité de l’intégration tout au long du cycle de développement logiciel, jusqu’au sein des outils de ticketing. Bon point également pour la détection des risques sur les composants IA, outputs de LLM compris.

Sur la supply chain logicielle, l’offre de Snyk a des limites (pas de détection des configs de pipelines non sécurisées et des plug-in vulnérables). Attention aussi à la prise en charge des langages de programmation (focalisation sur les langages « modernes »). Et à la personnalisation du reporting, perçue par la clientèle comme un point faible.

Pas d’option on-prem chez Veracode

Bon point aussi pour Veracode sur la gestion de la posture de sécurité des applications, en particulier par l’intégration de threat intelligence. Autres points forts : la remédiation par IA (pour le SAST, dans les IDE, les PR ou en CLI) et le support (tant l’offre principale que les options d’extension).

Veracode n’est disponible qu’en SaaS. Cela peut poser problème pour qui souhaite conserver son code en interne, même s’il existe une option de gestion des clés de chiffrement par le client. La détection des risques sur les composants IA apparaît perfectible (pas de gestion des injections de prompts et de la divulgation de données sensibles) comme la détection du statut des secrets (sont-ils valides ou non ?).

Illustration © Shahadat Rahman – Unsplash

The post Sécurité applicative : l’IA et la supply chain logicielle, inégalement couverts appeared first on Silicon.fr.

Au-delà du modèle de langage, il y a l’architecture.

On retiendra volontiers cet aspect des travaux que Lingua Custodia a menés dans le cadre du Large AI Grand Challenge.

Cette compétition s’est inscrite dans le projet européen AI-BOOST, censé en organiser 6 autres à l’horizon 2027 pour encourager l’innovation scientifique ouverte dans le domaine de l’IA. L’UE l’a doté pour cela d’une enveloppe de 4 M€.

3,2 millions d’heures GPU sur deux supercalculateurs EuroHPC

Le Large AI Grand Challenge avait été lancé en novembre 2023. Le contrat, dans les grandes lignes : développer, en partant de zéro, un LLM de fondation d’au moins 30 milliards de paramètres « plus performant que les systèmes à l’état de l’art sur un certain nombre de tâches ». Les lauréats recevraient chacun un prix de 250 000 € et 2 millions d’heures GPU sur un supercalculateur EuroHPC (LUMI, localisé en Finlande, ou LEONARDO, situé en Italie).

Des lauréats, il y en eut 4 (sur 94 dossiers), annoncés en juin 2024. Nommément, Textgain (Belgique), Tilde (Lettonie), Unbabel (Portugal)… et donc Lingua Custodia.
La PME francilienne – petite entreprise selon les seuils du Code de commerce – a choisi l’option LEONARDO. Fin 2024, elle a obtenu une allocation additionnelle de 1,2 million d’heures sur un autre supercalculateur EuroHPC : JUPITER, qui se trouve en Allemagne.

Nouvelle architecture… et nouvelle marque commerciale

Dans l’absolu, le premier modèle issu de ces travaux ne respecte pas le contrat : il ne compte « que » 3,6 milliards de paramètres. Il ne s’agit, par ailleurs, que d’un modèle dit « de base ». C’est-à-dire non affiné pour, par exemple, le dialogue ou le suivi d’instructions. Et donc non utilisable comme tel en production. Il faut néanmoins le voir comme un démonstrateur de la véritable valeur ajoutée : une architecture alternative à Transformers. Son nom : Dragon. Avec elle, Lingua Custodia change de cap. Ou tout du moins ouvre un nouveau chapitre. Jusque-là, on le connaissait effectivement plutôt pour ses services de traitement documentaire (classification, extraction, traduction, résumé…), fournis tant en SaaS que par API à destination du secteur financier.

Ce changement de cap s’assortit d’un changement de marque commerciale : exit Lingua Custodia, place à Dragon LLM.

Dépasser les limites de Transformers et de Mamba à l’inférence

L’architecture Dragon combine de multiples techniques existantes pour dépasser, en particulier, les limites que le mécanisme d’autoattention de Transformers présente lors de l’inférence. En l’occurrence, une consommation de ressources croissant avec la longueur des séquences (dans l’architecture de base, pour chaque token, le modèle examine tous les tokens précédents). Ces ressources, c’est du compute. Mais aussi de la mémoire, qui en vient à constituer le principal goulet d’étranglement, essentiellement en raison des limites de bande passante.

En réaction, des versions linéaires du mécanismes d’attention ont émergé. Évitant, d’un côté, la croissance quadratique de la consommation de ressources de calcul. Et permettant, de l’autre, l’utilisation d’un budget mémoire fixe. Ce en s’appuyant sur un état caché : une matrice ne conservant pas tous les tokens, mais une forme de « résumé évolutif ».

Cette approche a l’inconvénient de diminuer la précision des modèles. Dans ce contexte est apparue une architecture alternative : Mamba. Elle remplace le composant d’attention par un mécanisme inspiré de la théorie du contrôle : les SSM (State Space Models). Avec eux, la montée en charge est linéaire. Et surtout, on permet aux paramètres SSM d’être fonction de l’input, de sorte que la sélection des informations à conserver s’opère au moment de la mémorisation – et non au moment de la remémoration, comme c’est le cas avec Transformers.

Mamba a toutefois une faiblesse qui dissuade d’abandonner complètement l’autoattention : les modèles ne pas performants sur le rappel (recall). Cette métrique traduit la proportion de résultats positifs correctement classés comme tels. Elle est à différencier de la précision, qui indique le pourcentage de prédictions correctes parmi celles faites par le modèle.

Hymba, un socle made in NVIDIA

Dragon LLM a tenu compte des ces éléments pour mener ses expérimentations. Elles ont consisté à entraîner des modèles de 120 à 770 millions de paramètres sur un maximum de 50 milliards de tokens.

Pour l’amélioration de la fonction de perte, un benchmark a été ciblé : modded-NanoGPT. Pour le rappel, SWDE (prompts de 500 tokens) et FDA (2000 tokens) ont été mobilisés. Pour la évaluer la modélisation du langage, HellaSwag a été retenu.

Ces bases posées, Dragon LLM s’est intéressé à une autre architecture : Hymba (Hybrid Mamba). Signée NVIDIA, elle combine, dans chaque couche, des têtes d’attention classiques et des têtes SSM. Elle n’utilise une attention globale que sur 3 couches. Dans les autres cas, l’attention est locale (elle se limite aux 1024 derniers tokens). Les modèles fondés sur ce socle se montrent efficaces à l’inférence : leur débit se maintient à mesure que s’agrandit le contexte. La faiblesse sur le rappel demeure, cependant. D’où un choix d’explorer les mécanismes dits d’attention différentielle. Dragon LLM en mentionne deux, émanant respectivement de DeepSeek et de Microsoft. Les résultats du premier n’ont pu être reproduits de façon fiable. Le second, qui implique un système de suppression du bruit censé permettre au modèle de mieux repérer le contexte important, a produit des améliorations marginales lorsque appliqué à toutes les couches. En revanche, circonscrit à l’attention globale, il a eu un bénéfice significatif. Possiblement, nous explique-t-on, parce qu’il aurait stimulé une spécialisation de ces couches sur le rappel.

Un peu de DeepSeek dans l’affaire

D’autres techniques ont été mises en œuvre pour améliorer les performances de l’architecture Dragon. Parmi elles, la mise à l’échelle de la normalisation. Elle a eu pour effet de stabiliser la variance dans les couches profondes, ainsi mieux entraînées.

Dragon LLM a aussi remplacé l’initialisation des paramètres de PyTorch par un schéma origine DeepSeek. Et utilisé la planification SkyLadder, qui agrandit progressivement la fenêtre d’attention au fil de l’entraînement. Il a également opéré une normalisation individuelle des têtes d’attention (amélioration de l’intégrité du signal) et repositionné les couches d’attention globale (amélioration de la perte et du rappel) tout en supprimant l’encodage positionnel pour les têtes associées. Quant à la gestion d’état interne de Mamba, elle a été remplacé par la méthode GDN (Gated Delta Net), qui garantit de meilleures performances une fois passé le seuil des 30 milliards de tokens.

Certaines techniques n’ont pas porté leurs fruits. Par exemple, sur la data efficiency, Rho-1 et SoftDedup. L’une et l’autre pondèrent les tokens : elles utilisent un petit modèle qui leur attribue un score définissant leur contribution à la fonction de perte (les tokens plus « informatifs » influencent davantage les gradients).
De même, aucun optimiseur ne s’est révélé plus efficace qu’AdamW. Sinon Ademamix, mais avec des instabilités trop difficiles à gérer.

Les performances de SmolLM3, mais en plus frugal

Pour passer à l’échelle, Dragon LLM a implémenté son architecture dans le framework Megatron-LM. Le modèle qui en résulte est dit au niveau de Qwen3-4B et de SmolLM3. En tout cas sur ARC, FDA, HellaSwag, LAMBADA, PIQA et SWDE (en 0-shot). Le tout en plus frugal. Pour l’inférence, on l’a vu (DragonLLM évoque même un déploiement sur CPU), mais aussi pour l’entraînement (3700 milliards de tokens, soit 3 fois moins que SmolLM3 et 10 fois moins que Qwen3-4B).

Dragon LLM vise désormais un entraînement sur plus de 10 000 milliards de tokens, une adaptation au suivi d’instruction et la formation de plus gros modèles. Il promet des « versions dédiées à la production […] dans les prochains mois ».

À consulter en complément :

JUPITER, ce supercalculateur Arm qui met l’Europe dans l’ère exascale
IBM prend ses distances avec Transformers pour ses LLM Granite
Alibaba renonce à la « pensée hybride » pour ses LLM Qwen
Non divulgué, mal maîtrisé : Deloitte tancé pour son usage de l’IA générative
La GenAI, explorée mais peu déployée pour gérer les microservices

Illustration générée par IA

The post Architectures LLM : Dragon, une recette alternative origine France appeared first on Silicon.fr.

Ne dites plus Autonomous Data Warehouse, mais Autonomous AI Lakehouse.

Oracle opère ce changement de marque à l’aune de plusieurs évolutions fonctionnelles. Parmi elles, la gestion native du format Iceberg, d’où la notion de lakehouse. L’ajout d’un framework agentique justifie quant à lui l’aspect IA.

L’intégration Iceberg est initialement certifiée pour AWS Glue, Snowflake Polaris, Databricks Unity et Apache Gravitino. La syntaxe SQL d’Autonomous AI Database évolue en parallèle, pour permettre des requêtes de type select * from owner.table@catalog.

Après Select AI RAG, Select AI Agent

La partie agentique est nommée Select AI Agent. Elle s’inscrit dans la continuité de Select AI, lancé fin 2023 sous la bannière du text-to-SQL.

Depuis lors, Select AI a été doté, entre autres, d’une brique de RAG destinée notamment à enrichir les requêtes en langage naturel. Plus récemment, Oracle a mis à disposition un portage pour Python.

Le voilà donc qui s’ouvre à l’IA agentique, à l’appui d’un framework ReAct*. Il reprend la composante RAG, assortie d’une compatibilité MCP et de la capacité à exploiter des outils externes via REST (recherche web avec l’API OpenAI, en particulier). Quelque garde-fous sont mis en place, dont du LLM-as-a-judge pour évaluer les outputs et la possibilité de définir des « profils SQL » associés à des règles définies par l’utilisateur.

Table Hyperlink, nouveau nom des URL préauthentifiées

Le rebranding d’Autonomous Data Warehouse en Autonomous AI Lakehouse en appelle un autre : la fonctionnalité jusque-là appelée PAR URLs (Pre-Authenticated Request URLs) devient Table Hyperlink.

Le système des URL préauthentifiées permet de donner un accès temporaire, par client REST, à des tables ou à des vues dans Autonomous Database. Ces URL, générées par exécution de code PLSQL, peuvent avoir une date d’expiration et/ou un nombre maximal d’utilisations. On peut aussi les invalider manuellement. Depuis leur lancement début 2024, elles ont été enrichies sur plusieurs points. Dont, pour les producteurs de données, la possibilité d’étendre le délai de validité des URL en quelques appels API ; et un système de « partage sélectif » permettant de donner accès à des sous-ensembles de datasets sur le réseau Internet tout en conservant le reste dans un VCN (réseau virtuel privé). Pour les consommateurs de données, l’UI web s’est améliorée, avec par exemple un code couleur pour identifier tendances et anomalies.

La marque Table Hyperlink est censée mieux refléter l’objectif de cette fonctionnalité (connecter des tables à des workflows). Oracle promet d’y intégrer, à l’avenir, des variables d’association par défaut, d’assurer la cohérence pour les URL paginées… et surtout de permettre la gestion de plusieurs tables avec un même lien.

Dans le cadre des traitements de données externes, Oracle a intégré à sa base de données un système de cache sur mémoire flash (dans Exadata). Supportant les fichiers Parquet, ORC, AvRO et les tables Iceberg, il est pour l’instant manuel (c’est à l’utilisateur de définir les tables ou parties de tables à mettre en cache). Il est question d’automatiser le processus à partir de l’analyse des usages.

AI Data Platform, dans la lignée de MySQL HeatWave Lakehouse

On ne perçoit pas la dimension lakehouse dans le branding d’AI Data Platform, mais elle en est bien le fondement. L’offre, qui vient de passer en disponbilité générale, constitue une évolution d’un produit existant. En l’occurrence, MySQL HeatWave Lakehouse. Elle s’appuie sur Autonomous AI Database, Oracle Analytics Cloud (connexion possible avec des outils BI tiers), ainsi que le stockage objet et les services d’IA générative d’OCI (accès à des modèles de Meta, de Cohere, de xAI, etc.). La couche compute repose sur Apache Spark, assorti à du GPU NVIDIA. En ce sens, l’ensemble se distingue d’Autonomous AI Lakehouse, davantage orienté vers l’analytics.

Autonomous Data Warehouse et AI Data Platform sont à la base d’une autre offre, pas tout à fait nouvelle mais qui résulte aussi d’un changement de marque. Il s’agit de Fusion Data Intelligence, ex-Fusion Analytics Warehouse. Elle permet d’exploiter les outils d’analytics d’Oracle en lien avec les applications Fusion Cloud, en fournissant un pipeline, un entrepôt, un modèle sémantique et des contenus (métriques, workbooks, visualisations) prêts à l’emploi.

* Dans les grandes lignes, l’approche ReAct entrelace la génération des chaînes de pensée et la planification des actions en sollicitant du feedback humain si nécessaire.

Illustrations © Oracle

The post Le tandem lakehouse-IA s’impose dans le branding d’Oracle appeared first on Silicon.fr.

Finis la « plate-forme de communication », le « hub pour votre équipe et votre travail » ou le « remplaçant de l’e-mail » : Slack se voit désormais en « système d’exploitation agentique » (agentic OS).

L’éditeur joue cette carte à l’occasion de la Dreamforce 2025 (14-16 octobre). Il revendique une « transformation en un espace de travail conversationnel où les personnes, les IA et les agents collaborent, avec le contexte des conversations et des données ».

Dreamforce 2024 : du conversationnel, option agentique

Il y a un peu plus d’un an, à la Dreamforce 2024 (17-19 septembre), il n’était pas encore question d’agentic OS, mais de conversational work OS. Traduit alternativement, en version française, par « plateforme de travail », « plateforme collaborative »… et « système ». L’idée était par contre la même que celle prônée aujourd’hui : une « interface conversationnelle qui réunit les équipes, les données, les applications et les agents dans un environnement dédié ».

À ce moment-là, l’offre Agentforce dans Slack n’était pas encore disponible (elle allait passer en bêta en octobre 2024). La communication se portait plutôt, d’une part, sur l’installation d’applications « agentiques » via la marketplace (Claude et Perplexity étaient cités en exemple, avec la promesse d’une disponibilité imminente). De l’autre, sur la conception d’agents personnalisés à l’aide des API.

L’aspect agentique mis à part, la marque Slack AI était généreusement promue. Les fonctionnalités regroupées sous cette bannière sont aujourd’hui distillées dans les forfaits Slack payants :

• Pro (8,25 €/utilisateur/mois)
  Résumé de canaux et de threads, notes d’appels d’équipe (capture des infos importantes dans un canevas), compatibilité avec les assistants IA tiers.
• Business Plus (18 €)
  La même chose ainsi que des recaps IA quotidiens, le résumé de fichiers, la traduction et l’explication de messages, un générateur de workflows en langage naturel, une assistance à l’écriture dans les canevas et la recherche personnalisée (fondée sur les conversations et les fichiers partagés).
• Enterprise+
  La même chose avec, en complément, la recherche d’entreprise (exploitant les applications, bases de données et systèmes connectés à Slack).

L’intégration de ces fonctionnalités fut invoquée, mi-2025, pour justifier l’augmentation du prix du forfait Business+. La com de Slack était alors à cheval entre le conversational work OS et l’agentic OS : il était question de « système d’exploitation professionnel à l’ère des agents IA » (work operating system for the agentic era).

Du général au particulier

Agentforce dans Slack étant passé en disponibilité générale début 2025, il est désormais au cœur du message. La description assez générique qui en avait été donnée à la Dreamforce 2024 a laissé place à la mise en avant de cas spécifiques, pour les ventes (Agentforce Sales), le support informatique (Agentforce IT Service), la gestion des ressources humaines (Agentforce HR Service) et la datavisualisation (Agentforce Tableau).

Parallèlement, un usage généraliste est promu à travers Channel Expert. Cet agent activable dans tous les canaux peut pour le moment exploiter conversations, canevas, listes, fichiers texte et PDF. Il nécessite une licence Agentforce.

Slack s’adresse aussi aux développeurs d’applications. Il leur annonce la disponibilité d’un serveur MCP, donnant initialement accès aux conversations, aux fichiers et aux canevas. Il évoque aussi un élément récemment ajouté à son API : un bloc facilitant l’affichage de données tabulaires au sein de messages.

Avec les IA, une API devenue moins ouverte

L’API a connu, dernièrement, une évolution plus marquante, corollaire d’une démarche de restriction de l’accès aux données. Slack a effectivement modifié, fin mai, les conditions d’utilisation, essentiellement pour empêcher les exportations massives de données. L’éditeur en a interdit le stockage et l’indexation « longue durée », tout en précisant qu’elles ne pouvaient servir à entraîner des LLM. En parallèle, il a mis en place un plafonnement des débits (nombre de requêtes par minute et de messages par requête) sur les méthodes conversations.history et conversations.replies pour les applications commerciales non distribuées sur sa marketplace.

L’API RTS (Real-Time Search), promue de la bêta à la « disponibilité limitée » à l’occasion de la Dreamforce, s’inscrit dans cette même logique : elle permet d’exploiter des données sans les sortir de Slack. Les applications ChatGPT, Google Agentspace et Dropbox Dash, entre autres, en font usage. Perplexity Enterprise se connecte quant à lui au serveur MCP.

Initialement rattaché à l famille Slack AI, Slackbot commence, en tout en façade, à tendre vers l’agentique. À terme, il devra « réaliser des actions en votre nom et construire des agents sur votre demande », nous annonce-t-on. En l’état, on se tournera vers la brique Agent Builder, en exploitant éventuellement les quelques templates récemment ajoutés (Customer Insights, Employee Help, Onboarding).

À consulter en complément, un point sur l’évolution du branding côté Salesforce, entre chatbots, copilotes , agents… et dilution de la marque Einstein.

Illustration © Slack

The post D’une Dreamforce à l’autre, comment Slack entretient la flamme de l’IA agentique appeared first on Silicon.fr.

La dette d’Altice France restructurée, Bouygues Telecom, Free et Orange sortent du bois.

Après des mois de discussions, les trois opérateurs viennent de déposer une offre conjointe portant sur SFR. Elle a été immédiatement rejetée.

Voici quelques éléments de contexte chiffrés.

17 milliards d’euros

Le montant de l’offre.
Bouygues Telecom en apporterait 43 % (7,3 Md€) ; Free, 30 % (5,1 Md€) ; Orange, 27 % (4,6 Md€).

L’activité B2B serait reprise par Bouygues Telecom principalement, et par Free.
L’activité B2C serait partagée entre les trois opérateurs.
Les autres acteurs et ressources – notamment infrastructures et fréquences – seraient également partagées.
Le réseau mobile SFR en zone non dense serait repris par Bouygues Telecom.

4 participations

L’offre exclut explicitement quatre participations d’Altice. En l’occurrence :

• Intelcia
  Filiale d’outsourcing (centre de contact, recouvrement, conseil en IT…). 40 000 collaborateurs.
• UltraEdge
  Résultat de la scission des activités datacenter de SFR, effectuée en 2024 avec l’arrivée du fonds d’investissement Morgan Stanley Infrastructure Partners.
  250 sites, dont 90 utilisables en colocation (plus de 500 m² de surface IT installée) ; 45 MW de puissance disponible.
  SFR est resté client (pour ses activités télécoms) et actionnaire minoritaire.
• XPFibre
  Ex-SFR FTTH. Opérateur d’infrastructures spécialisé dans les réseaux de fibre optique. Intervient dans les zones peu et moyennement denses (AMEL, AMII et RIP). Créé en 2019 avec la prise de participation à 49,9 % d’AXA, Allianz et du fonds canadien OMERS. Renommé en 2021 après l’absorption de Covage.
• Altice Technical Services
  ERT Technologies (1350 salariés ; née en 2000) est sa principale entité. Elle conçoit, construit, exploite et assurance la maintenance d’infrastructures réseau.

80 MHz

La taille du bloc de fréquences que SFR est autorisé à exploiter sur la « bande cœur » de la 5G (3,4 – 3,8 GHz). L’attribution s’est déroulée en 2020. Orange a obtenu 90 MHz ; Bouygues Telecom et Free, 70 MHz chacun.

SFR déploie aussi la 5G sur la bande dite des 2100 Mhz. Il y dispose de 15 MHz en liaison montante (1920,5 – 1935,5 MHz) comme en liaison descendante (2110,5 – 2125,5 MHz).

L’opérateur dispose également de 5 MHz duplex dans la bande des 700 MHz, attribuée en 2015 dans le cadre du deuxième dividende numérique (récupération de fréquences exploitées par la TNT).

15 345 sites

Au 1^er octobre 2025, le volume de sites 5G SFR techniquement opérationnels en France métropolitaine (pour 18 989 sites autorisés).
Le compteur en était à 16 800 chez Bouygues Telecom (20 686 autorisés), 21 938 chez Free (25 947 autorisés) et 14 797 chez Orange (17 608 autorisés).

• Bande des 700 MHz
  SFR : pas de sites
  Bouygues Telecom : pas de sites
  Free : 20 911 sites opérationnels (25 415 autorisés)
  Orange : 12 007 sites opérationnels (13 679 autorisés)
• Bande des 2100 MHz
  SFR : 10 944 sites opérationnels (14 637 autorisés)
  Bouygues Telecom : 16 489 sites opérationnels (20 582 autorisés)
  Free : pas de sites
  Orange : 1674 sites opérationnels (2688 autorisés)
• Bande des 3,5 GHz
  SFR : 10 086 sites opérationnels (12 555 autorisés)
  Bouygues Telecom : 10 037 sites opérationnels (12 544 autorisés)
  Free : 9762 sites opérationnels (12 309 autorisés)
  Orange : 13 075 sites opérationnels (15 084 autorisés)

D’après Altice, le réseau 5G de SFR couvrait, au 30 juin 2025, 84,5 % de la population.

25,415 millions de clients

Fixe et mobile confondus, SFR comptait un peu plus de 25 millions de clients au 30 juin 2025.

Sur le fixe, ils étaient 6,109 millions, contre 6,227 millions un an plus tôt (- 1,9 %). Ce volume correspond au nombre d’utilisateurs finaux ayant souscrit à au moins un service basé sur la fibre, le câble ou les box 4G.

Sur le mobile aussi, SFR a perdu des clients. En un an, sa base est passée de 19,624 à 19,306 millions (- 1,6 %).

2028

L’horizon auquel SFR doit « redevenir l’opérateur préféré des Français en proposant le meilleur rapport qualité-prix du marché ».

Tel est en tout cas l’objectif affiché par Altice dans le cadre de son plan SFR Imagine lancé en octobre 2024. En toile de fond, le recentrage sur son activité télécoms. Il a impliqué la vente d’Altice Médias (BFMTV et RMC) à CMA-CGM pour environ 1,5 Md€.

15,5 milliards de dette

Altice France chiffrait sa dette financière nette à 23,773 Md€ au 30 juin 2025.

Elle a depuis été restructurée, et ainsi réduite à 15,5 Md€. En contrepartie, les créanciers montent à 45 % du capital (Patrick Drahi conservant ainsi une participation majoritaire).

Le groupe était entré en procédure de sauvegarde accélérée au mois de mai. Le tribunal des affaires économiques de Paris avait donné son feu vert à la restructuration de dette en août. L’opération a ouvert la voie à la vente de SFR.

Sur le premier semestre 2025, Altice France a réalisé un chiffre d’affaires de 4,746 Md€ (- 7,1 % par rapport à la même période en 2024). Dont :

• 1,294 Md€ sur le segment fixe résidentiel (- 4,6 %)
• 1,636 Md€ sur le mobile résidentiel (- 10,6 %)
• 1,43 Md€ sur le segment business services (- 5,7 %)*

Le résultat opérationnel a chuté de 25,3 %, à 645,6 M€, malgré une nette réduction des achats et de la sous-traitance. Comme, dans une moindre mesure, des autres dépenses d’exploitation (portée entre autres par l’automatisation du service client à renfort d’une IA basée sur Gemini). La perte nette s’est élevée à 368,3 M€.

* Le segment business services inclut les revenus les revenus associés à la location de l’infrastructure réseau à d’autres opérateurs. Il comprend aussi les activités datacenter, la production et la distribution de contenu, les services client et technique, ainsi que la construction de réseaux FTTH.

Illustration © Maxime Dufour Photographies

The post Rachat de SFR : 7 chiffres pour contextualiser la première offre appeared first on Silicon.fr.

Pour ce qui est des « travailleurs de première ligne » (frontline workers), les fournisseurs d’intranets restent largement en phase d’apprentissage.

D’année en année, Gartner réitère le constat dans le Magic Quadrant qu’il dédie à ce marché. La dernière édition n’y déroge pas.

Autre élément récurrent : l’absence de Microsoft, en dépit de l’influence qu’il a sur ce segment. Et pour cause : Gartner limite toujours son périmètre aux « solutions packagées » (IPS, Intranet Packaged Services), définies comme « prêts à l’emploi ». Par opposition à SharePoint, qui nécessite des composantes externes (de Microsoft ou de tierces parties), en tout cas pour satisfaire aux critères fonctionnels évalués.

Reste que Microsoft est l’éditeur avec lequel tous les fournisseurs d’IPS doivent composer. Certains se greffent sur des locataires Office 365 quand d’autres utilisent SharePoint pour gérer le contenu et/ou mettent en place des intégrations avec des éléments comme Entra ID, Teams et le Microsoft Graph.

Peu de fournisseurs ont des solutions verticales voire déploient un effort marketing et commercial dans ce sens, ajoute Gartner. Ce critère a toutefois eu un poids faible dans l’évaluation.

16 fournisseurs, 7 « leaders »

L’axe « exécution » du Magic Quadrant reflète la capacité à répondre effectivement à la demande. La situation est la suivante :

Rang	Fournisseur	Évolution annuelle
1	Unily	+ 1
2	Simpplr	– 1
3	LumApps	+ 3
4	Workvivo by Zoom	+ 1
5	Omnia	nouvel entrant
6	ServiceNow	+ 5
7	Blink	nouvel entrant
8	Staffbase	+ 1
9	Firstup	– 1
10	Interact	=
11	Appspace	+ 2
12	MangoApps	– 8
13	Haiilo	– 1
14	Akumina	– 11
15	Powell	– 8
16	Axero	– 1

Sur l’axe « vision », censé refléter les stratégies (géographique, sectorielle, commerciale, marketing, produit…) :

Rang	Fournisseur	Évolution annuelle
1	LumApps	+ 3
2	Simpplr	– 1
3	Unily	– 1
4	Workvivo by Zoom	+ 1
5	Interact	+ 2
6	MangoApps	+ 5
7	Akumina	+ 2
8	Firstup	– 2
9	Staffbase	– 6
10	Powell	+ 3
11	Omnia	nouvel entrant
12	Haiilo	+ 2
13	Appspace	– 3
14	ServiceNow	– 6
15	Axero	– 3
16	Blink	nouvel entrant

Les fournisseurs classés « leaders » sont les mêmes que dans le précédent Magic Quadrant des IPS :  Firstup, Interact, LumApps, Simpplr, Staffbase, Unily et Workvivo.

Firstup, pas le mieux placé pour la gestion du travail et du contenu

Gartner salue la stratégie marketing de Firstup, capable de cibler un large éventail de profils d’acheteurs. Il apprécie aussi la gestion du premier contact et de l’onboarding. Bons points également pour l’expérience client (gestion de compte, collecte de feedback, promotion des communautés) et la viabilité de l’entreprise (santé financière, base de clientèle, engagement R&D).

Firstup n’est pas le mieux placé pour répondre aux exigences qui vont au-delà de la communication multicanale et du frontline, pour toucher par exemple à la recherche d’entreprise, à l’IA et à la gestion de contenu. Il ne propose, par ailleurs, pas de capacités « traditionnelles » de gestion du travail (assignation de tâches, automatisation de workflows…). Gartner note aussi l’absence de solutions verticales et le défi de passage à l’échelle – ventes, marketing, support, développements personnalisés – pour Firstup, qui n’est pas un pure player.

Idéation, newsletters, affichage dynamique… Des briques moins matures chez Interact

Interact a aussi droit à un bon point sur son marketing, tant pour la stratégie que pour l’exécution. Il se distingue également par sa compréhension des profils d’acheteurs ; et, en conséquence, par sa capacité à contextualiser ses offres. Gartner apprécie de surcroît son niveau de présence au sein des organisations de moins de 25 000 employés et l’extensibilité de sa solution. Ainsi que la prise en charge du frontline, entre autres par des intégrations avec des systèmes de gestion du travail.

Certaines briques d’Interact sont moins matures que son cœur fonctionnel. Par exemple, l’idéation, les newsletters et l’affichage dynamique. Attention également au modèle largement direct, qui limite les ressources dans certaines régions géographiques (Asie-Pacifique et Amérique latine, notamment). On prendra par ailleurs garde d’avoir les ressources nécessaires si on apporte ses propres modèles sur le back-end IA.

Mise en place et gestion complexes pour LumApps

Gartner salue l’exhaustivité de l’offre de LumApps et son adaptabilité à beaucoup de cas d’usage. Il apprécie aussi son extensibilité (orchestration et automatisation de workflows, développement de mini-apps) et les fonctionnalités IA qui lui ont été greffées, tant pour les admins que les gestionnaires de contenus et les utilisateurs finaux.

La mise en place et la gestion peuvent s’avérer complexes, même avec l’assistance par GenAI. LumApps manque par ailleurs de notoriété dans certaines régions et en dehors de son cœur de marché. La clientèle étant essentiellement composée d’organisations de moins de 10 000 employés, les plus grandes auront sont d’étudier si le support leur conviendra.

Chez Simpplr, un manque de cohésion entre communication et gestion de contenu

Simpplr se distingue par ses efforts sur l’orchestration. Ainsi que sur l’IA, gouvernance comprise (utilisation de NVIDIA NeMo Guardrails et de Langfuse). Gartner apprécie aussi la qualité des interactions client (marketing, vente, partenaires) et l’efficacité de la solution en matière de gestion du travail.

Présent surtout en Amérique du Nord, Simpplr a une distribution géographique moins équilibrée que ses concurrents. Gartner ajoute que la partie communication multicanale manque de cohésion vis-à-vis de la gestion de contenu, qui n’est plus globalement par le fort de Simpplr. Le cabinet américain note aussi un focus R&D parfois au détriment des ventes et du marketing.

IA, orchestration et extensibilité, des faiblesses de Staffbase

Staffbase a pour lui son niveau de compréhension du marché, porté par son expérience sur la partie communication entre employés. Son intégration de longue date avec Microsoft lui permet de bien couvrir à la fois employés de bureau et frontline. L’empreinte géographique (distribution du revenu, réseau de partenaires, versions localisées) est un autre point fort. Comme la santé financière de l’entreprise et ses investissements en R&D.

Staffbase peut être perçu comme globalement immature sur l’IA pour qui cherche des capacités avancées de gestion du travail, de service aux employés et d’optimisation data-driven. Gartner relève aussi des faiblesses dans l’orchestration et l’extensibilité. Ainsi que les défis qu’est susceptible de poser le focus de Staffbase sur l’aspect communication.

Tarification peu transparente chez Unily

Bon point marketing également pour Unily, onboarding compris. Gartner apprécie aussi le réseau de partenaires et d’intégrations, la capacité de collecte de feedback et la disponibilité de solutions sectorielles.

Unily a une présence limitée dans les entreprises de moins de 10 000 salariés – certaines ressentent qu’elles ne sont pas une priorité. Gartner relève aussi le manque de transparence de sa tarification, les limites sur les fonctionnalités IA (analyse de recherche, simulation d’audience, UI adaptatives) et le support (temps de réponse et d’escalade).

Workvivo pousse le social/communautaire au détriment d’autres use cases

En plus de pouvoir s’appuyer sur les ressources et la notoriété de Zoom, Workvivo opère un positionnement markting efficace. Gartner apprécie ses programmes d’accompagnement client et l’accent mis sur le développement de communautés internes.

En matière de gestion du travail et d’extensibilité, il y a mieux, explique le cabinet américain. Workvivo est globalement jugé trop agressif sur le sujet social/communautaire au détriment d’autres cas d’usage. Vigilance aussi pour qui veut standardiser sur Teams : l’expérience front-end est brandée Workvivo, mais le back-end est branché sur Zoom.

Illustration générée par IA

The post Digital workplace : le frontline, défi persistant pour les fournisseurs d’intranets appeared first on Silicon.fr.

AWS orchestre un grand ménage dans ses services de modernisation.

Migration Hub et Application Discovery Service sont passés en mode maintenance. Pour le moment jusqu’au 7 novembre 2025, date à partir de laquelle ils n’accepteront plus de nouveaux clients*. Il en sera de même à cette échéance pour les outils de modernisation .NET**. Tandis que Mainframe Modernization Service n’existera plus qu’en version autogérée.

Le palliatif désigné, lancé il y a quelques mois sous la bannière de l’IA agentique, s’appelle AWS Transform.

Quantité d’autres services passeront en mode maintenance à partir du 7 novembre 2025. En voici quelques-uns.

Amazon Cloud Directory

Magasin de données hiérarchisées, alternatif aux annuaires LDAP. Les écritures seront bloquées dans un deuxième temps (passé le 22 avril 2026). Puis le service fermera le 30 septembre 2026 et le contenu sera supprimé en parallèle. AWS n’y a plus ajouté de fonctionnalités depuis 2018 et le lancement d’Amazon Neptune, base de données orientée graphe vers laquelle il recommande aujourd’hui de migrer.

Amazon CodeCatalyst

À partir du 7 novembre, il ne sera alors plus possible, pour les utilisateurs existants, de créer de nouveaux espaces. AWS recommande de migrer vers l’offre GitLab Duo with Amazon Q. Ou alors vers CodeBuild (compilation et test de code), CodePipeline (orchestration CI/CD), CodeDeploy (déploiement d’applications) et Code Artifact (gestion de packages).

Amazon CodeGuru Reviewer

Service d’analyse de code Java et Python sur Bitbucket, CodeCommit, GitHub et S3). À partir du 7 novembre 2025, il ne sera plus possible de créer de nouvelles associations de dépôts. Options de migration recommandées : Amazon Q Developer et Amazon Inspector, qui couvrent l’un et l’autre GitHub et GitLab.

Amazon S3 Object Lambda

Ce service permet l’ajout de code aux requêtes S3 GET, HEAD et LIST pour modifier des données. Il n’acceptera plus de nouveaux utilisateurs à la même date. AWS recommande d’invoquer Lambda par d’autres moyens (via CloudFront, API Gateway ou les URL de fonctions) ou de traiter les données dans les applications clientes.

Amazon Glacier

Le passage en maintenance d’Amazon Glacier interviendra un peu plus tard. Le 15 décembre 2025 en l’occurrence. On parle là du service d’origine, autonome, basé sur un coffre-fort avec API REST. Les données stockées jusque-là resteront accessibles indéfiniment, assure AWS, qui recommande de faire la transition vers les classes de stockage Glacier dans S3. Lesquelles ont l’avantage d’une disponibilité plus large sur son cloud, d’une intégration avec ses autres services, d’un coût inférieur et d’une API niveau bucket.

AWS IoT SiteWise Monitor et Data Procesing Pack

Deux composantes de l’offre AWS IoT SiteWise passeront également en mode maintenance le 7 novembre 2025. D’une part, le Data Processing Pack  (transformation, stockage et visualisation de données). De l’autre, Monitor (création de portails web pour visualiser et partager des données au sein d’une organisation). Pour remplacer le premier, AWS recommande soit l’open source (Node-RED pour la transformation, InfluxDB pour le stockage de séries chronologiques, Grafana pour la visualisation), soit des solutions de partenaires (CloudRail, EasyEdge, Litmus Edge). Au second, il conseille de substituer le plug-in Amazon Managed Grafana (en sachant qu’il n’y a pas de contrôle d’accès niveau asset ni d’intégration avec AWS IoT SiteWise Assistant) ou bien Grafana Cloud ou autohébergé.

AWS Snowball Edge

Appliances de transfert de données. L’offre n’acceptera plus non plus de nouveaux clients à compter du 7 novembre 2025. Successeurs recommandés : DataSync pour les transfert sur lien réseau et Data Transfer Terminal pour les transferts physiques (Seagate et Tsecond soit également cités). Pour remplacer l’appliance optimisée compute, il y a éventuellement l’offre AWS Outposts.

Amazon Fraud Detector

Détection de fraude à base de machine learning. En guise de remplacement, AWS avance son WAF (pare-feu pour applications web), son service SageMaker (MLOps)… et une bibliothèque open source dont il est à l’origine : AutoGluon (AutoML à partir d’images, de texte, de séries chronologiques et de données tabulaires).

Accès web à Amazon WorkSpaces sur PCoIP

AWS recommande d’installer, si possible, les clients Amazon WorkSpaces. Sinon, de migrer vers le protocole DCV. Qui a, entre autres avantages :

• Meilleures performances
• Fonctionnalités supplémentaires (SAML et authentification par certificats, notamment)
• Disponibilité étendue (pas d’accès web sur PCoIP dans certaines régions AWS, dont Paris)
• Gestion des bureaux Linux en plus de Windows
• Fonctionnement dans Edge et Safari en plus de Chrome et Firefox
• Gestion des écrans multiples et des GPU côté hôte

* Sur Migration Hub comme sur Application Discovery Service et Mainframe Modernization Service, les projets en cours pourront être menés à leur terme.

** Cela comprend Porting Assistant for .NET, AWS App2Container, AWS Toolkit for .NET Refactoring et AWS Microservice Extractor for .NET.

Illustration © Annika – Adobe Stock

The post De Glacier à CodeCatalyst, AWS range nombre de services au placard appeared first on Silicon.fr.

Pour la gestion des API, la tendance est à l’approvisionnement auprès de plusieurs fournisseurs.

Gartner avait fait la remarque l’an dernier dans le Magic Quadrant consacré à ce marché. Il va plus loin cette année : le sourcing multiple est devenu standard… en contrepartie d’un risque de fragmentation que peuvent toutefois atténuer les architectures fédérées.

Un autre mouvement s’est confirmé : une part croissante des utilisateurs de solutions de gestion des API sont des développeurs. Les stratégies marketing ont évolué en conséquence. Mais des offreurs gardent un déficit de visibilité auprès de ce public. Y compris quelques-uns de ceux que Gartner classe comme « leaders ». En l’occurrence, Axway, Boomi et, dans une certaine mesure, IBM.

17 fournisseurs, 7 « leaders »

En 2024, Boomi faisait partie des « acteurs de niche ». En un an, il a nettement progressé, tant en « exécution » (capacité à répondre effectivement à la demande du marché) qu’en « vision » (stratégies : sectorielle, géographique, commerciale, marketing, produit…). Axway et IBM étaient quant à eux déjà « leaders ». Même chose pour Google Cloud, Gravitee, Kong et Salesforce. On ne peut pas en dire autant de SmartBear, qui a rétrogradé chez les « visionnaires ».

Sur l’axe « exécution », la situation est la suivante :

Rang	Fournisseur	Évolution annuelle
1	Google	=
2	IBM	=
3	Salesforce	+ 2
4	Kong	+ 5
5	Boomi	+ 8
6	Axway	– 3
7	Gravitee	+ 3
8	WSO2	+ 6
9	Microsoft	– 5
10	SAP	– 3
11	AWS	– 5
12	Sensedia	+ 5
13	SmartBear	– 2
14	Tyk	– 6
15	Workato	nouvel entrant
16	Postman	– 1
17	Solo.io	– 1

Sur l’axe « vision » :

Rang	Fournisseur	Évolution annuelle
1	Kong	=
2	Boomi	+ 12
3	Gravitee	+ 3
4	Salesforce	+ 3
5	IBM	– 1
6	Google	– 4
7	Tyk	+ 4
8	Postman	– 5
9	Axway	– 4
10	SmartBear	– 2
11	Microsoft	+ 1
12	Workato	nouvel entrant
13	SAP	=
14	WSO2	– 5
15	Sensedia	=
16	Solo.io	– 6
17	AWS	=

Axway : avec le chantier iPaaS, moins d’agilité sur l’IA

Comme l’an dernier, Axway se distingue sur la gestion fédérée des API. Gartner salue de plus le lancement récent d’une brique iPaaS. Il apprécie aussi la manière dont les partenariats (Stoplight, Ping, Graylog, Traceable…) viennent renforcer le modèle économique, au même titre que les acquisitions (en particulier celle de Sopra Banking Software, dont la fusion avec Axway a donné 74Software). Bon point également pour la capacité d’internationalisation, entre documentation multilingue et UI localisées.

Également comme l’an dernier, la notoriété auprès des développeurs reste limitée. Axway est par ailleurs plus lent que la concurrence pour livrer des fonctionnalités IA « avancées » (le focus sur l’iPaaS l’explique en partie, comme la restructuration de sa stack autour de la notion d’événements). Gartner relève, en parallèle, une croissance des ventes bien inférieure à la moyenne du marché.

Boomi manque d’accroche auprès des développeurs

L’année écoulée aura marqué un tournant dans la vision de la gestion des API chez Boomi, de sorte que ce dernier dépend désormais moins du seul iPaaS pour se différencier.  L’acquisition d’APIIDA et de TIBCO Mashery a accompagné la refonte de l’offre, assortie d’une feuille de route que Gartner salue. Dans le même temps, la présence commerciale de Boomi s’est étendue, tant du point de vue géographique qu’au travers du renforcement de partenariats (ServiceNow et AWS en particulier).

Sur la gestion des API, Boomi reste, relativement aux autres « leaders », un petit acteur en termes de revenus et de part de marché. Il n’a pas non plus la même empreinte auprès des développeurs (son marketing reste perçu comme axé sur les métiers et les décideurs IT). Vigilance également quant à l’intégration avec les passerelles tierces : elle peut s’avérer complexe.

Apigee « généreusement » poussé comme complément à GCP

Google Cloud se distingue sur le volet innovation, entre autres parce qu’il a greffé à Apigee de quoi favoriser la conception d’API par des agents (avec prise en charge des protocoles A2A et MCP). Gartner apprécie aussi les possibilités offerts en matière de monétisation du trafic IA et de détection des usages abusifs. Il y ajoute la stabilité du produit et sa capacité à remplir les cas d’usage les plus complexes… sous réserve de disposer de l’expertise adéquate.

Google Cloud continue néanmoins à positionner ses produits comme des compléments à GCP plutôt que comme des solutions autonomes. Des clients signalent, de surcroît, qu’on les incite à migrer. Le produit en lui-même est relativement complexe à exploiter. Et malgré des changements positifs sur la tarification, des clients de longue date expriment leur inquiétude quant au rapport coût/bénéfices.

Gravitee n’a toujours pas sectorialisé son offre

Outre un déploiement flexible, Gravitee a pour lui l’indépendance vis-à-vis de tout cloud, progiciel ou iPaaS. Gartner souligne qu’il a su rapidement proposer une passerelle IA gérant le protocole MCP (et destinée à s’ouvrir aux maillages agentiques). Bon point également pour la performance commerciale (CA déclaré en croissance de 70 % sur un an), doublée d’une tarification simple.

Par rapport aux autres « leaders », Gravitee manque de notoriété. Il n’a toujours pas « verticalisé » son approche. Et sa clientèle reste largement concentrée en Europe (les acheteurs sur d’autres plaques géographiques se poseront la question du service et du support).

IBM, peu pris en considération hors de son écosystème

IBM est crédité d’un bon point pour la couverture fonctionnelle de son offre. Il l’est aussi pour la flexibilité de déploiement et la livraison de fonctionnalités axées IA (gestion des prompts, routage LLM). Gartner salue également la diversité de sa clientèle (tailles, régions, secteurs) ainsi que de son réseau commercial et de support.

L’acquisition de webMethods a produit un doublon au catalogue (voire plus si on considère que Red Hat a sa propre offre de gestion d’API), qui demeure en l’état même si IBM a promis une convergence. Big Blue a par ailleurs tendance à toucher essentiellement les organisations qui sont ses clients sur d’autres segments (il est peu évalué sinon). Et sur l’année écoulée, ses ventes ont connu une croissance sous la moyenne du marché.

Kong : une tarification qui peut prêter à confusion

Kong se distingue par les fonctionnalités AI-driven qu’il a livrées dernièrement (génération d’API, de spécifications et de serveurs MCP). Il parvient par ailleurs à conserver une forte visibilité, à renfort d’événements, de partenariats et de présence sur les principales marketplaces. Gartner salue aussi le lancement des Serverless Gateways (passerelles « légères » sans serveur) et de l’Event Gateway (qui permet de gérer des flux Kafka), intégrée avec son maillage de services.

Comme chez Gravitee, pas de solutions sectorielles au catalogue. Attention aussi à la courbe d’apprentissage que supposent les solutions Kong, en plus de la confusion que peuvent susciter la tarification basée sur les services et les frais supplémentaires pour des éléments comme les portails, les tests et l’analytics. Gartner y ajoute une présence limitée en Amérique du Sud, au Moyen-Orient et en Afrique comparé aux autres « leaders ».

Salesforce reste un des fournisseurs les plus chers

En complément à la présence commerciale et au réseau de partenaires, Gartner note que Salesforce a réussi à s’étendre sur le segment SMB (small and medium business, entreprises de moins de 1000 employés), qui représente 30 % du business de MuleSoft. L’intégration avec le reste de son offre a contribué à attirer une grosse base de clientèle. Salesforce jouit globalement d’une grande notoriété de marque, y compris auprès des développeurs.

En plus de rester l’un des fournisseurs les plus chers, MuleSoft présente une structure de prix complexe susceptible d’entraîner des coûts imprévus. Il est par ailleurs perçu comme plus réactif qu’innovant, en particulier pour ce qui touche à l’IA. Et les capacités restent limitées sur la monétisation comme le test d’API, ainsi que la fédération de passerelles.

Illustration © Murrstock – Adobe Stock

The post Gestion des API : le sourcing multiple est devenu standard appeared first on Silicon.fr.

Il va falloir s’y habituer : les « agents Joule » se multiplient au catalogue de SAP.

L’éditeur allemand vient d’en annoncer 14 supplémentaires. Ils seront intégrés d’ici à mi-2026 dans certains de ses logiciels.

Quatre de ces agents visent les métiers de la finance :

• Accounting Accruals (tenue du journal comptable)
• Cash Management (gestion de trésorerie)
• International Trade Classification (conformité aux règles du commerce international)
• Receipts Analysis (traitement des notes de frais)

Trois sont dans le domaine de la supply chain :

• Change Record Management (gestion du changement)
• Product Planning and Operations (planification de la production et gestion de l’exploitation)
• Supplier Onboarding (embarquement des fournisseurs)

Trois également dans les RH :

• Career and Talent Development (gestion de carrière)
• HR Service (traitement des demandes des employés)
• People Intelligence (rétention et gestion des compétences)

Un agent s’adresse aux achats (Bid Analysis ; analyse des offres). Deux touchent à la gestion des processus (Process Content Recommender et Workspace Administration). S’y ajoute un agent sectoriel (Utilities Customer Self-Service, ciblant les fournisseurs d’énergie).

Ces 14 agents en rejoignent 17 autres. Les voici, avec leur stade de développement, les produits concernés et – pour certains – quelques-unes des promesses chiffrées que leur associe SAP.

Finance

Accounts Receivable (gestion des créances)
En bêta, pour S/4HANA Cloud Private Edition.
Recommande des actions selon le profil et l’historique du paiement du client.
Promesses*, entre autres : 75 % de temps en moins pour l’analyse et la réconciliation (de 20 à 5 minutes par dossier) et réduction de 2 % du taux de passage en pertes et profits (de 1 à 0,98 %).

Booking (gestion des réservations)
En accès anticipé, pour Concur Travel.
Recommande vols et hébergement selon le voyageur, les politiques de l’entreprise et les contraintes budgétaires.

Dispute Resolution (résolution des litiges)
En bêta, pour S/4HANA Cloud Private Edition.
Promesses, entre autres : réduction de 30 % du temps de gestion de litige (de 20 à 14 minutes) et de 5 % du taux de churn associé (de 0,25 à 0,238 %).

Expense Report Validation (validation des rapports de dépenses)
En accès anticipé, pour Concur Expense.
Promesses : réduction de 30 % du temps de préparation et de soumission (de 30 à 21 minutes par rapport) et de 25 % du taux de rejet (de 15 à 11,4 %).

Meeting Location Planner (organisation de réunions hors site)
En accès anticipé, pour Concur Travel.
Promesses : réduction de 10 % des dépenses annuelles par employé concerné (de 3975 à 3488 €) et de 15 % du temps de planification par réunion (de 5 heures à 4 heures 15 minutes).

Supply chain

Field Service Dispatcher (gestion des ressources)
En bêta, pour SAP Field Service Management.

Maintenance Planner (planification de la maintenance)
En bêta, pour S/4HANA Cloud Private Edition.
Promesses : réduction de 40 % du temps nécessaire à la création des backlogs (de 120 à 72 minutes par jour) et de 1 % du taux d’arrêts imprévus (de 92 à 92,1 % d’uptime).

Shop Floor Supervisor (supervision de la production en atelier)
En bêta, pour SAP Digital Manufacturing.
Promesses : réduction de 50 % du temps passé à gérer les perturbations (de 60 à 30 minutes par jour) et de 2 % du taux d’arrêts non planifiés (de 92 à 93,8 % d’uptime).

CX

Case Classification (tri de cas)
Disponible pour Sales Cloud Version 2, Service Cloud Version 2 et dans le cadre de SAP CX AI Toolkit.

Catalog Optimization (optimisation de catalogue)
En bêta, pour Commerce Cloud et dans le cadre de CX AI Toolkit.

Digital Service (réponse aux questions des équipes de vente et de service client)
En accès anticipé, dans le cadre de CX AI Toolkit.

Knowledge Creation (création de bases de connaissances à partir de tickets résolus)
Disponible pour Sales Cloud Version 2, Service Cloud Version 2 et dans le cadre de CX AI Toolkit.

Q&A (réponse aux questions des clients)
Disponible pour Sales Cloud Version 2, Service Cloud Version 2 et dans le cadre de CX AI Toolkit.

Quote Creation (création de devis)
Disponible pour Sales Cloud et dans le cadre de CX AI Toolkit.
Automatise la création de devis à partir d’une boîte mail Office 365 partagée.

Shopping (accompagnement du parcours client)
Disponible pour Commerce Cloud et CX AI Toolkit.
Promesses, entre autres : hausse de 10 % du taux de conversion (de 3 à 3,3 %) et du panier moyen (de 309 à 340 €).

Les agents CX actuellement commercialisés ne peuvent être achetés qu’à travers le package Joule Premium for Customer Experience. Lequel inclut, outre les agents, une vingtaine de fonctionnalités « étiquetées IA » (détection de comptes en double, création de descriptions de produits, aide à la génération de leads…).

Un agent est dédié aux RH (Performance and Goals, censé aider à préparer les entretiens d’évaluation). Un autre aux achats (Sourcing, illustré ci-dessous, qui automatise les RPF ; il est en bêta, pour Ariba Sourcing).

* SAP dit baser ses estimations sur « des cas clients, des benchmarks et d’autres recherches ».

Illustrations © SAP

The post Où en est SAP Joule dans son tournant agentique ? appeared first on Silicon.fr.