Vue lecture

Panne AWS : 10 incidents dont la région us-east-1 fut l’épicentre

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.

  •  

Veeam rachète Securiti AI pour 1,73 milliard $

Le groupe américain Veeam Software, détenu par le fonds d’investissement Insight Partners va racheter Securiti AI pour environ 1,73 milliard $ en numéraire et en actions.

L’opération, qui doit être finalisée d’ici la fin de l’année, marque une étape clé dans l’évolution de Veeam, traditionnellement centrée sur la sauvegarde et la restauration des données, vers un rôle plus large de gardien de la confiance numérique.

« Cette acquisition nous permet d’unifier la résilience, la sécurité et la gouvernance des données au sein d’une même plateforme », a déclaré le directeur général de Veeam, Anand Eswaran, précisant que l’opération devrait commencer à contribuer aux bénéfices dès le second semestre 2026.

Résilience et gouvernance des données

Historiquement, Veeam a bâti sa réputation sur la protection contre les ransomwares et les pannes informatiques. Avec Securiti AI, l’entreprise s’attaque à un nouveau champ : celui de la protection des données exploitées par les modèles d’intelligence artificielle.

L’enjeu est crucial : dans un environnement où les IA génératives manipulent d’immenses volumes d’informations, les risques de fuites, de biais ou de violations de la confidentialité explosent.

« L’intelligence artificielle d’entreprise n’est pas possible sans sécurité des données », résume Rehan Jalil, fondateur et PDG de Securiti AI, qui rejoindra Veeam en tant que président en charge de la sécurité et de l’IA.

Le communiqué officiel de Veeam détaille l’ambition technique du rapprochement : offrir un “single control plane”, c’est-à-dire un plan de contrôle unique couvrant les données de production et les données secondaires (sauvegardes, archives, environnements cloud ou SaaS).

Cette intégration permettra aux directions informatiques de cartographier l’ensemble de leur patrimoine de données, d’en contrôler les accès et d’en assurer la conformité avec les réglementations internationales.

Securiti AI apporte sa plateforme Data Command Center, fondée sur un  (graphe de connaissances qui relie les informations de sécurité, de confidentialité et de gouvernance. La solution est complétée par un moteur d’automatisation “agentic AI”, un module de recherche d’entreprise sécurisé “Gencore AI”, et des fonctions avancées de Data Security Posture Management (DSPM) et de gouvernance de la donnée.

« Notre objectif est de permettre aux clients d’avoir une visibilité complète sur leurs données, qu’elles soient en production, en sauvegarde ou en transit », explique Anand Eswaran.

Répondre à la complexité des environnements IA

Selon Veeam, 70 à 90 % des données d’entreprise sont non structurées — e-mails, documents, messages clients — et 80 à 90 % des projets d’IA échouent en raison de problèmes liés à la qualité, à la confidentialité ou à la gestion des accès. En combinant ses solutions de résilience avec l’expertise de Securiti AI en sécurité des données, Veeam veut proposer une réponse complète à cette complexité croissante.

Le rachat, valorisé 1,725 milliard $, a été financé par JPMorgan Chase & Co. et conseillé par Morgan Stanley du côté de Securiti AI.Basée à San Jose (Californie), Securiti AI emploie environ 600 personnes et avait été valorisée 575 millions $ en 2023, après une levée de fonds de 75 millions $ menée par Capital One Ventures et Citi Ventures. Parmi ses investisseurs figurent General Catalyst et Mayfield.

De son côté, Veeam, rachetée en 2020 par Insight Partners pour 5 milliards $, revendique 6 000 employés et plus de 550 000 clients dans le monde, dont 67 % des entreprises du Global 2000. En décembre 2024, elle avait été valorisée 15 milliards $ lors d’une opération secondaire menée par TPG, avec la participation de Temasek et Neuberger Berman.

Vers une “data confidence platform” pour l’ère de l’IA

En combinant les savoir-faire des deux entreprises, Veeam entend créer une plateforme de confiance pour les données (“data confidence platform”), unifiant la sauvegarde, la gouvernance et la sécurité des informations dans un contexte multi-cloud.

Les premières solutions communes devraient être présentées dans les mois suivant la clôture du rachat. L’ambition est claire : faire de Veeam un pilier de la sécurité des données à l’ère de l’intelligence artificielle, où la fiabilité des modèles dépendra autant de la puissance des algorithmes que de la qualité — et de la protection — des données sous-jacentes.


Eclairage 

Le “control plane” :  outil central du pilotage des données


Appliqué à la donnée, le “control plane” vise à offrir une vue consolidée sur l’ensemble des informations détenues par une organisation, qu’elles soient stockées dans le cloud, sur site, en sauvegarde ou utilisées par des modèles d’IA.

Concrètement, un “control plane” unifié comme celui que veut bâtir Veeam doit permettre de :

  • recenser toutes les données d’entreprise, quelle que soit leur source ;

  • contrôler les droits d’accès et les permissions ;

  • surveiller les usages et détecter les comportements à risque ;

  • automatiser la conformité avec des réglementations comme le RGPD ou le CCPA ;

  • et orchestrer la sécurité de bout en bout, y compris pour les systèmes d’IA générative.

Ce concept, emprunté au monde du réseau et du cloud, devient aujourd’hui le socle d’une gouvernance de la donnée à l’ère de l’intelligence artificielle, où la frontière entre sauvegarde, sécurité et conformité tend à disparaître.


Photo : © Veeam

The post Veeam rachète Securiti AI pour 1,73 milliard $ appeared first on Silicon.fr.

  •  

Project Mercury : comment OpenAI veut disrupter les banques d’affaires

OpenAI a discrètement lancé un projet visant à . Baptisé Project Mercury, ce programme mobilise plus de 100 anciens employés de grandes banques d’investissement, dont JPMorgan Chase, Morgan Stanley et Goldman Sachs, pour former son IA à la construction de modèles financiers complexes.

Un projet pour révolutionner la finance

Selon des documents obtenus par Bloomberg, les participants au Project Mercury sont rémunérés pour rédiger des instructions (prompts) et concevoir des modèles financiers couvrant divers types de transactions, comme les restructurations ou les introductions en Bourse (IPO). En échange, ces experts bénéficient d’un , conçue pour remplacer les tâches de base des analystes financiers.

Les analystes en banque d’investissement consacrent souvent à des tâches répétitives : construction de modèles Excel pour des fusions ou des rachats par effet de levier (LBO), ou ajustements interminables de présentations PowerPoint. Une culture du « pls fix » (« merci de corriger »), devenue virale sur les réseaux sociaux, symbolise cette réalité.

Le Project Mercury s’inscrit dans une dynamique plus large où des startups cherchent à automatiser ces processus. Si les jeunes banquiers se plaignent depuis longtemps de la monotonie de ces tâches, l’émergence de l’IA soulève désormais des questions sur la pérennité de leur emploi.

Un

L’accès au projet ne nécessite presque aucune interaction humaine. Les candidats passent d’abord un entretien de 20 minutes avec un chatbot, suivi d’un test sur les états financiers et d’une épreuve de modélisation. Une fois sélectionnés, ils doivent produire , en respectant des (marges, mise en italique des pourcentages, etc.). Leurs travaux sont ensuite évalués et intégrés aux systèmes d’OpenAI.

Parmi les participants figurent d’anciens employés de Brookfield, Mubadala, Evercore ou KKR, ainsi que des étudiants en MBA de Harvard et du MIT.

Interrogé par Bloomberg, un porte-parole d’OpenAI a déclaré que l’entreprise collabore avec des experts de différents domaines, recrutés et gérés par des prestataires tiers, pour « améliorer et évaluer les capacités de ses modèles ».

Si le Project Mercury reste confidentiel, son impact potentiel est immense. En automatisant les tâches de base, OpenAI pourrait redéfinir le rôle des analystes financiers, tout en accélérant la .

The post Project Mercury : comment OpenAI veut disrupter les banques d’affaires appeared first on Silicon.fr.

  •  

OVHcloud franchit le milliard d’euros de chiffre d’affaires

OVHcloud, le plus grand fournisseur de cloud en Europe, annonce une croissance annuelle de près de 10%, franchissant pour la première fois la barre symbolique d’un milliard d’euros de chiffre d’affaires, atteignant 1,08 milliard € pour l’exercice 2025. L’EBITDA ajusté de la société a atteint 40,4%, reflétant une solide rentabilité.

Cependant, les prévisions pour 2026 ont surpris le marché à la baisse. OVHcloud table sur une croissance organique du chiffre d’affaires comprise entre 5% et 7% pour l’exercice en cours, bien en deçà des 9,3% enregistrés en 2025 et des attentes des analystes, qui anticipaient environ 10%. À la suite de cette annonce, les actions de la société ont chuté d’environ 18%, s’orientant vers leur plus forte baisse quotidienne historique si la tendance se maintient.

Sur le plan opérationnel, OVHcloud prévoit une augmentation de sa marge EBITDA ajustée et des dépenses d’investissement représentant entre 30% et 32% du chiffre d’affaires, dans le but de renforcer son segment Webcloud.

Les ventes de Cloud privé explosent

La répartition des revenus montre que les ventes de « Private Cloud » ont progressé de 8,5%, représentant 62% du total, tandis que le « Public Cloud » a connu une croissance de 17,5% pour 20% du chiffre d’affaires. Le segment « Webcloud » a augmenté de 3,7%, représentant 18% du total.

Le groupe, qui dessert près de 1 200 clients, poursuit également son expansion internationale, avec une demande croissante au Canada, à Singapour et en Inde. OVHcloud reste en concurrence avec les géants américains Amazon Web Services, Microsoft Azure et Google Cloud.

Par ailleurs, la société a annoncé le retour immédiat de son fondateur Octave Klaba au poste de P-DG, après que le conseil d’administration a décidé de fusionner les fonctions de président et de directeur général. La famille Klaba détient plus de 80% du capital d’OVHcloud.

Enfin, OVHcloud a reconnu un appel d’offres de 180 millions € lancé par la Commission européenne le 10 octobre pour des infrastructures cloud, sans commenter davantage les discussions en cours. « Cela prend du temps, mais nous sommes heureux de constater que le marché évolue dans la bonne direction », a déclaré Octave Klaba.

The post OVHcloud franchit le milliard d’euros de chiffre d’affaires appeared first on Silicon.fr.

  •  

Panne AWS : la région us-east-1, point faible connu mais persistant

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.

  •  

OVHcloud : Octave Klaba reprend le poste de P-DG

Back to 2018 dans la gouvernance de OVHcloud…Octave Klaba, le fondateur du groupe reprend le poste de P-DG. Il occupait depuis 2018 le poste de Président du conseil d’administration et la présidence du comité stratégique et de la RSE du groupe.

C’est à cette date qu’il avait recruté Michel Paulin, dirigeant expérimenté du secteur Télécom en provenance de SFR, au poste de directeur général, pour développer le groupe sur le créneau du “cloud souverain et durable” face aux hyperscalers américains, avec notamment l’adoption du nouveau nom OVHcloud et l’introduction en Bourse en 2021.

Un an après le départ de Michel Paulin, Octave Klaba reprend donc la totalité de l’exécution des opérations. « L’idée est de réunir la vision, la stratégie et l’exécution afin de faire profiter plus rapidement à nos clients, les 10 ans d’investissement lourd dans les Datacenters (250MW) et dans le Software (40 produits Public Cloud).» explique-t-il dans un post LinkedIn.

La barre du milliard de chiffre d’affaires franchi en 2025

Un plan stratégique baptisé « Step Ahead » pour la période 2026-2030 va être présenté dans les prochains mois.

« En plus de continuer à accompagner les clients Corporate et Digital Scalers, je reviens pour nos clients historiques Digital Starters, les « petits clients » comme ils disent, afin de leurs proposer de l’innovation, de l’AI, le prix/performance, un meilleur support, la facturation plus simple .. ces prochains mois vont être riches en annonce ..» poursuit Octave Klaba.

En 2025, OVHcloud vient de franchir pour la première fois la barre du milliard d’euros de chiffre d’affaires (1 084,6 M €) et dégagé un résultat net positif ( 400 millions) avec un Ebitda de 40,4 %.

The post OVHcloud : Octave Klaba reprend le poste de P-DG appeared first on Silicon.fr.

  •  

La sécurité des IA agentiques pose question

Gartner évoquait un marché devant passer de 5,1 milliards $ en 2024 à 47,1 milliards en 2030… Déjà, Visa et Mastercard proposent des solutions de commerce agentique pour permettre à des agents de réaliser des achats en ligne…

Cette nouvelle approche pose d’évidentes questions de cybersécurité. Si un attaquant venait à prendre le contrôle d’un agent autonome, il pourrait déstabiliser le fonctionnement interne d’une entreprise et, s’il s’agit d’un agent orienté B2C avoir accès aux données personnelles des clients ou vider le compte en banque des clients.

Lors du salon In Cyber 2025, Proofpoint a présenté une interaction entre deux agents sécurisée via sa solution. Xavier Daspre, Directeur technique France de l’éditeur Proofpoint explique son approche : « Les deux agents sont traités comme des postes de travail qui se connectent par échange d’email ou surtout par API vers des services Cloud public. Pour nous, l’approche reste la même. Pour l’instant, le comportement des agents est plus cadré et beaucoup plus facilement discernable, mais cela va être amené à évoluer. Dans les cas d’usage actuels, nos solutions sont déjà prêtes à protéger ce cas d’usage un peu particulier. »

Le côté obscur des agents

Les fournisseurs de services anti-DDoS sont habitués à gérer des bots depuis des années. Ils développent des algorithmes et entraînent des modèles de Machine Learning pour trier le trafic généré par les humains de celui des bots légitimes et des bots illicites.

Pour Sébastien Talha, Directeur régional des ventes de Human Security, les agents sont déjà massivement exploités par les attaquants : « 80 % des attaques utilisent aujourd’hui des robots, car les attaquants ont besoin d’agir à grande échelle » explique le responsable. « L’intervention humaine n’arrive qu’en fin d’attaque, lorsque l’attaquant a besoin de réaliser des opérations complexes. On imagine qu’avec l’IA agentique, cela va disparaître. »

Face aux bots basés sur l’IA, les mécanismes du type mesure de la vitesse de l’utilisateur au clavier, mouvements de la souris ou modèles de navigation pour détecter s’il s’agit d’un humain ou d’un robot ne seront plus suffisants. « L’attaquant peut simuler la vitesse de frappe, enregistrer des déplacements de souris et les rejouer automatiquement. »

Human Security a créé plus de 350 modèles de Machine Learning pour déjouer les attaques par bot et son capteur collecte plus de 2 500 paramètres techniques sur l’utilisateur liés à son réseau, son terminal et son comportement. Il va devoir adapter son approche pour faire face à l’arrivée d’IA agentiques « légitimes ».

MCP,  pilier de la sécurisation

Son concurrent français DataDome mise beaucoup sur l’analyse comportementale pour détecter une fraude lors d’une session, en complément des paramètres techniques comme l’adresse IP, la géolocalisation, le type de terminal. « Dans les aspects comportementaux, on analyse les mouvements de souris, si le comportement, les requêtes et le cheminement de navigation dans la session ne correspond pas au comportement habituel de l’utilisateur sur le site ou l’application » explique Benjamin Barrier, Chief Strategic Officer et cofondateur de DataDome.

« Le comportemental permettra de détecter les IA illégitimes et les IA agentiques qui ont « pignon sur rue », notamment Operator d’OpenAI, mettent en œuvre des protocoles tels que MCP pour nous permettre une authentification forte des agents. C’est la combinaison de ces deux approches qui vont permettre d’atteindre une protection efficace de ces IA agentiques. »

Le prestataire a déjà commencé le référencement des opérateurs d’IA agentiques qui ont pignon sur rue, et travaille sur le protocole MCP (Model Context Protocol) pour sécuriser les échanges. Ce protocole est amené à prendre de plus en plus d’importance dans la sécurisation des IA agentiques, car c’est lui qui permet d’interagir avec l’agent, lui passer des paramètres, que ce soit d’une application vers un LLM, ou d’agent à agent.

Les meilleures pratiques de MCP recommandent l’utilisation de TLS pour les connexions distantes, une validation de tous les messages entrants, la protection des ressources, notamment avec du contrôle d’accès et une gestion stricte des erreurs

The post La sécurité des IA agentiques pose question appeared first on Silicon.fr.

  •  

À 40 ans, la FSF enclenche un projet pour un Android vraiment libre

À 40 ans, la FSF (Free Software Foundation) s’est donné un nouvel objectif : éliminer les éléments propriétaires qui demeurent dans les distributions Android.

C’est le principe du projet LibrePhone, lancé en août et officiellement annoncé début octobre.

En ligne de mire, les pilotes de bas niveau (Bluetooth, Wi-Fi, capteur d’empreintes digitales, écran tactile…). Il s’agit de les remplacer par du logiciel libre sur « au moins un téléphone moderne ».

LineageOS comme base de travail

LibrePhone est financé par l’informaticien John Gilmore – qui fut un des premiers employés de Sun Microsystems. La direction technique a été confiée à Rob Savoye (DejaGNU, Gnash, OpenStreetMap…).

La première phase, censée durer environ 6 mois, doit permettre de comprendre la manière dont le noyau Linux utilise les pilotes en question. Et ainsi d’estimer les ressources nécessaires pour effectuer un reverse engineering dans le cadre légal. Après quoi un appareil sera ciblé.

Les travaux se fondent sur les packages d’installation de LineageOS (environ 200 appareils pris en charge). Divers scripts ont été développés pour en extraire les pilotes et les examiner.

À consulter en complément :

Comment Google veut fusionner ChromeOS et Android
Un « vrai » mode desktop prend forme sur Android
Android suit iOS sur le redémarrage automatique des appareils

Illustration générée par IA

The post À 40 ans, la FSF enclenche un projet pour un Android vraiment libre appeared first on Silicon.fr.

  •  

IA frugale : 6 bonnes pratiques « secondaires » du référentiel AFNOR

À 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.

  •  

Claude Skills, game changer pour les LLM ?

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.

  •  

AWS lance quatre certifications dédiées à l’IA et au ML

Amazon Web Services (AWS) annonce le lancement de quatre nouvelles certifications centrées sur l’intelligence artificielle (IA) et l’apprentissage automatique (ML). L’hyperscaler s’attaque à structurer la validation des compétences dans un domaine en forte expansion, en couvrant à la fois les profils non techniques et les ingénieurs spécialisés.

Elles couvrent différents niveaux de maîtrise, du plus généraliste au plus avancé.

Jusqu’à présent, AWS ne proposait qu’une seule certification dédiée au machine learning, de niveau « Specialty ». L’introduction de ces quatre nouveaux examens établit un parcours progressif, allant de la compréhension des concepts à la maîtrise opérationnelle des outils de l’écosystème AWS.

Une structuration plus claire des parcours IA

La certification AI Practitioner marque l’entrée dans cet univers, en abordant les principes fondamentaux de l’IA sans nécessiter de compétences en programmation.
Les certifications Machine Learning Engineer – Associate et Data Engineer – Associate s’adressent à des profils techniques impliqués dans la mise en œuvre et la gestion des données nécessaires à l’entraînement des modèles.
Enfin, Generative AI Developer – Professional, la plus avancée, cible les spécialistes capables d’intégrer et d’optimiser des modèles génératifs en production, notamment via des services comme Amazon Bedrock.

Ces certifications offrent un cadre de reconnaissance standardisé pour les professionnels souhaitant démontrer leur maîtrise des outils d’IA dans l’environnement AWS. Elles peuvent contribuer à clarifier les compétences sur le marché du travail, tout en favorisant la montée en qualification sur des technologies très demandées.

Elles restent toutefois étroitement liées à l’écosystème AWS, ce qui limite la transférabilité directe des compétences vers d’autres plateformes cloud. La rapidité d’évolution du secteur oblige par ailleurs à actualiser fréquemment les référentiels d’examen, afin de suivre les évolutions technologiques et les bonnes pratiques.

La version bêta de l’examen Generative AI Developer illustre cette dynamique : elle sera ajustée avant sa version finale en fonction des retours des premiers candidats.

Quatre certifications pour quatre niveaux de spécialisation

Nom de la certification Niveau / catégorie Public visé & prérequis Contenu / compétences évaluées Particularités (durée, format, langue, coût)
AWS Certified AI Practitioner Fondamental (Foundational) Professionnels non techniques ou débutants connaissant les bases de l’IA/ML Concepts d’IA et de machine learning, cas d’usage, principes d’IA responsable, services AWS liés à l’IA 90 minutes, 65 questions, coût 100 USD, disponible en français, en ligne ou en centre Pearson VUE
AWS Certified Machine Learning Engineer – Associate Niveau Associate Ingénieurs ou développeurs ayant une expérience en IA/ML sur AWS Développement, déploiement, maintenance et supervision de modèles à l’échelle Certification orientée sur la mise en production de modèles d’IA dans AWS
AWS Certified Data Engineer – Associate Niveau Associate Professionnels en charge de la gestion et de la préparation de données Conception d’architectures, création de pipelines, qualité et orchestration des données 130 minutes, 65 questions, coût 150 USD
AWS Certified Generative AI Developer – Professional Niveau Professionnel Développeurs expérimentés en IA/ML souhaitant concevoir des applications génératives Utilisation de modèles de base, ingénierie de prompts, bases vectorielles, optimisation des performances et sécurité Examen bêta de 204 minutes, 85 questions, coût 150 USD

The post AWS lance quatre certifications dédiées à l’IA et au ML appeared first on Silicon.fr.

  •  

ESN 2025 : liste du Top 50 en France

 

Classement 2025 des ESN— Chiffre d’affaires France (k€)
Rang Entreprise Chiffre d’affaires France (k€)
1 CAPGEMINI 4 380 000
2 SCC FRANCE 2 925 000
3 ACCENTURE 2 605 592
4 SOPRA STERIA 2 440 000
5 ORANGE BUSINESS 1 800 000
6 ATOS 1 760 000
7 IBM FRANCE 1 723 300
8 CGI FRANCE 1 547 970
9 ALTEN 1 360 300
10 ECONOCOM 1 230 000
11 COMPUTACENTER 1 159 974
12 INETUM 1 030 000
13 DOCAPOSTE 825 000
14 NEURONES 810 400
15 AKKODIS 782 800
16 EQUANS DIGITAL 699 307
17 THALES SERVICES NUMERIQUES 631 000
18 CEGEDIM 592 963
19 SPIE ICS 553 000
20 KYNDRYL 520 000
21 TALAN 510 000
22 AXIANS 505 000
23 TESSI 487 542
24 OVHCLOUD 485 983
25 INOP’S 462 000
26 SII GROUP 455 840
27 SOLUTIONS30 ETC 450 000
28 DXC FRANCE 440 793
29 OPEN 415 000
30 FASTOR GIE 400 180
31 GROUPE ASTEK 391 000
32 SCALIAN 380 000
33 MAGELLAN PARTNERS 365 000
34 ADISTA 350 000
35 HELIAQ 338 852
36 NXO 329 600
37 INHERENT 304 000
38 AUBAY 283 300
39 VISEO 270 000
40 HELPLINE 268 000
41 INFOTEL 266 776
42 EXTIA 241 000
43 EXPERIS 240 000
44 CONSTELLATION 211 733
45 ACENSI 203 382
46 CHEOPS TECHNOLOGY 190 421
47 MC2I 181 000
48 HARDIS GROUP 179 088
49 KEYRUS 176 000
50 NÉOSOFT 175 000

———————–

Entre ralentissement économique et mutation structurelle, les ESN à la croisée des chemins

L’étude publiée par Numeum et KPMG France décrit une conjoncture défavorable, où les tensions économiques et la faiblesse de la demande pèsent sur l’activité.

  • 42 % des entreprises anticipent un véritable redémarrage au premier semestre 2026.

  • 85 % identifient les risques macroéconomiques et la demande insuffisante comme les principaux freins à la croissance.

Cette situation traduit une rupture avec les années de forte expansion du numérique. Elle met en lumière la nécessité pour le secteur de repenser ses fondements économiques et ses sources de valeur ajoutée.

Recomposition de la proposition de valeur

L’étude souligne une évolution profonde du modèle d’affaires des prestataires numériques.
Les directions informatiques, désormais en quête de partenaires durables, privilégient la qualité et la pertinence de la valeur délivrée plutôt que le volume de prestations.

La performance est de plus en plus évaluée à travers trois dimensions :

  • la capacité d’innovation,

  • la compétence technique et méthodologique,

  • la responsabilité sociale et environnementale des acteurs.

Cette redéfinition du rapport client-prestataire marque une transition vers une logique de partenariat stratégique plutôt qu’opérationnel.

L’intelligence artificielle générative comme moteur de transformation

L’IA générative s’impose comme le principal levier d’opportunité pour les entreprises du secteur.

  • 81 % la désignent comme la première source de croissance, devant la transformation digitale (58 %) et la cybersécurité (56 %).

  • 72 % l’intègrent déjà dans leurs processus de production (delivery) et 67 % dans leurs fonctions administratives.

  • Près de la moitié des entreprises disposent de compétences internes en IA, confirmant une intégration rapide et durable de cette technologie.

L’IA devient ainsi un facteur structurant du repositionnement stratégique du numérique français, combinant innovation technologique et rationalisation des coûts.

Ressources humaines : montée en compétences et nouvelles attentes

La transition vers des modèles fondés sur la valeur s’accompagne d’une reconfiguration des besoins en talents.
Les profils les plus recherchés concernent :

  • le conseil en transformation digitale (19 % des besoins exprimés),

  • les spécialistes du cloud (17 %),

  • les experts en cybersécurité (9 %).

Les leviers de fidélisation des collaborateurs reflètent une évolution des priorités :

  • la rémunération demeure déterminante (63 %),

  • la progression professionnelle et les opportunités de projets comptent pour 18 %,

  • la flexibilité et l’équilibre de vie pour 14 %.

Ces chiffres traduisent un équilibre recherché entre attractivité financière et qualité des conditions de travail.

Responsabilité environnementale : un critère désormais structurant

La responsabilité environnementale s’impose comme une dimension incontournable de la performance.

  • 79 % des entreprises se fixent des objectifs de réduction de leur empreinte carbone.

  • 67 % des grandes entreprises prennent déjà en compte l’impact environnemental dans le choix de leurs prestataires.

  • Près d’un tiers des répondants visent la neutralité carbone à l’horizon 2030.

La durabilité devient un axe de compétitivité autant qu’une contrainte réglementaire et réputationnelle.

Méthodologie :
L’étude est établie à partir des données collectées par Numeum et KPMG durant le deuxième trimestre 2025, auprès d’un échantillon représentatif de près de 200 ESN et ICT de toutes tailles, implantées en France. Les informations ont été recueillies via un questionnaire en ligne portant sur les thèmes suivants : stratégie de croissance, gestion des talents, initiatives Environnementales, Sociales et de Gouvernance (ESG) et innovation.
Les données déclarées, notamment celles concernant les unités, ont été corrigées en cas d’erreurs manifestes.

The post ESN 2025 : liste du Top 50 en France appeared first on Silicon.fr.

  •  

Sécurité applicative : l’IA et la supply chain logicielle, inégalement couverts

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.

  •  

Valorisation des startups IA : bulle or not bulle ?

Selon les relevés du Financial Times, dix jeunes entreprises d’intelligence artificielle non rentables ont vu leur valorisation combinée augmenter de près de 1 000 milliards $ au cours des douze derniers mois, un bond inédit qui ravive les inquiétudes d’une bulle spéculative sur les marchés privés du capital-risque.

Les jeunes entreprise les plus en vue, tels qu’OpenAI, Anthropic et xAI ont bénéficié de multiples revalorisations en 2024, portées par l’enthousiasme des investisseurs pour l’IA générative. D’autres acteurs, dont Databricks, Perplexity ou Figure AI, ont également profité de la vague d’investissements.

Une ruée sans précédent du capital-risque

Les fonds américains de capital-risque ont consacré environ 161 milliards $ à l’IA depuis le début de l’année, soit près des deux tiers de leurs investissements totaux, d’après les données de PitchBook citées par le FT. À ce rythme, les dépenses annuelles des investisseurs dans l’intelligence artificielle devraient dépasser 200 milliards $ en 2025, contre 135 milliards investis dans les start-up logicielles en 2021.

Cette concentration inédite des capitaux sur un nombre restreint d’acteurs fait craindre une surchauffe du marché. « Bien sûr qu’il y a une bulle », admet Hemant Taneja, directeur général du fonds General Catalyst. « Les bulles alignent le capital et le talent autour de nouvelles tendances. Elles provoquent des dégâts, mais elles font aussi émerger des entreprises durables qui changent le monde. »

Certains investisseurs estiment que les niveaux de valorisation actuels sont devenus difficilement justifiables. Le FT rapporte que des startup générant à peine 5 millions $ de revenus récurrents annuels (ARR) tutoient désormais des valorisations dépassant 500 millions $, soit des multiples de plus de 100 fois leurs revenus — bien au-delà des excès observés lors de la période de taux zéro.

Un capital-risqueur de la Silicon Valley cité par le quotidien finanacier souligne que le marché semble considérer « comme exceptionnelles des entreprises qui ne le sont pas ».

Des paris massifs, mais risqués

Malgré ces signaux d’exubérance, de nombreux acteurs du secteur continuent de parier sur le potentiel transformateur de l’IA. Marc Benioff, fondateur et directeur général de Salesforce, estime qu’un trillion de dollars d’investissements pourrait être perdu, mais que la valeur créée à long terme sera « dix fois supérieure ».

Cette effervescence dans le non coté a des effets directs sur les marchés publics. Le FT note que les actions de Nvidia, AMD, Broadcom ou Oracle ont gagné des centaines de milliards de dollars de capitalisation boursière à la suite d’accords conclus avec OpenAI. Toutefois, une remise en cause de la solvabilité de cette dernière pourrait inverser brutalement cette dynamique.

Trois ans après le lancement de ChatGPT, OpenAI génère environ 13 milliards $ de revenus annualisés, une croissance fulgurante pour une start-up. Mais la course à l’intelligence artificielle générale (AGI), qui oppose notamment OpenAI, Google et Meta, demeure extrêmement coûteuse et incertaine.

Pour l’auteur et spécialiste du capital-risque Sebastian Mallaby, cité par le FT , la logique des investisseurs se résume ainsi : « Si nous atteignons l’AGI, tout cela aura valu la peine ; sinon, non. »

The post Valorisation des startups IA : bulle or not bulle ? appeared first on Silicon.fr.

  •  

Architectures LLM : Dragon, une recette alternative origine France

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.

  •  

Guillaume Rincé, CTO du Groupe MAIF : « Nous fonctionnons comme un éditeur de logiciels »

À la tête de la stratégie technologique de la MAIF, Guillaume Rincé conduit une transformation en profondeur du système d’information du groupe mutualiste. Entre développement interne des logiciels, engagement fort en faveur de l’open source et réflexion sur la souveraineté numérique, il défend une vision responsable et maîtrisée du numérique.

Dans cet entretien, il revient sur la manière dont la MAIF conjugue innovation, indépendance technologique et valeurs mutualistes, de la gestion du cloud à l’usage raisonné de l’intelligence artificielle générative.

Silicon – Quel est votre périmètre d’activité en tant que CTO de la MAIF ?
Guillaume Rincé – J’ai deux activités principales. D’abord, je définis la stratégie en matière de système d’information pour l’ensemble du groupe et de ses filiales. Ensuite, j’ai la responsabilité des activités technologiques du groupe. Nous fonctionnons de manière matricielle avec des équipages qui regroupent les grands métiers développeurs, ingénieurs, business analystes, designers, architectes, etc. Et puis nous avons des activités de « delivery » organisées en tribus, selon notre vocabulaire, qui correspondent aux différents domaines métiers de la MAIF :  par exemple la tribu « Canaux et flux » ou la tribu « IARD Sinistres ».

J’anime les domaines technologiques et mon collègue Sébastien Agard s’occupe de toute la partie des livrables fonctionnels. Ensuite nous mélangeons nos équipes dans ces tribus qui sont constitués d’équipiers qui viennent des différents métiers du groupe pour réaliser les applications que nous mettons à disposition.

La MAIF est éditeur de ses propres logiciels ?
Oui, nous développons la majorité de nos applications en interne. Nous avons recruté plusieurs centaines de collaborateurs, dont beaucoup de développeurs, pour cela ces dernières années. Nous fonctionnons comme un éditeur de logiciels organisé pour produire nos propres solutions et les mettre en œuvre. Cela nous donne une maîtrise complète de la chaîne, que ce soit en termes de compétences, de ressources ou de processus, y compris le design, qui est clé pour améliorer l’expérience utilisateur.

Dans cette activité d’éditeur, vous vous appuyez beaucoup sur l’open source ?
L’Open Source est une démarche naturelle pour la MAIF, en accord avec notre raison d’être qui est d’œuvrer pour le bien commun. Fabriquer des communs et les partager, c’est complètement en phase avec les valeurs du groupe. Quand je dis “open source”, je ne parle pas d’une techno de container habillée, fournie par un éditeur avec une politique de souscription fermée. Je parle de vraies distributions open source, véritablement libres.
Nous utilisons beaucoup de technologies à travers des Framework comme React ou des bases de données PostgreSQL.

Nous avons une dizaine de produits disponibles sur notre plateforme GitHub (http://maif.github.io), que d’autres peuvent intégrer dans leurs systèmes d’information. Par exemple, nous partageons un API management à l’état de l’art, que nous utilisons nous-mêmes à l’échelle du groupe. Nous le maintenons activement. Nous avons des utilisateurs dans la presse, dans la vente, et dans d’autres domaines, pas seulement en France, mais aux quatre coins du monde.

Nous partageons aussi des technologies de « Feature Flipping » pour activer du code à chaud,ou encore d’explicabilité des algorithmes d’IA et nous contribuons activement à des projets open source, notamment pour maintenir certains composants critiques. Nous avons des personnes qui s’investissent dans différentes technologies. Ce sont souvent des contributions aux « quick fixes ». Nous aimons soutenir des projets que nous utilisons, surtout ceux qui sont importants pour nos systèmes d’information mais qui sont portés par peu de personnes.

Chaque année, nous essayons de soutenir 2 à 3 projets par des dons en euros ou en aidant à financer une librairie. L’idée est de soutenir ceux qui créent ces composants utiles et dont nous bénéficions, en reversant une partie des économies que nous réalisons grâce à l’Open Source.

Comment se déroule l’identification des besoins, le développement et la production des applications ?
L’objectif est que ce soit un sujet de toute l’entreprise, et non pas uniquement de la DSI.
Il faut pouvoir intégrer cette transformation au niveau des métiers qui interagissent avec nous. Dans notre organisation, plusieurs éléments structurent ce processus. Le premier, c’est ce que nous appelons le portefeuille stratégique d’initiatives. L’idée est simple : nous avons un certain nombre d’orientations stratégiques.  Très souvent, derrière ces orientations, se cachent des sujets liés au système d’information, mais pas uniquement. Chaque orientation est portée par ce que nous appelons des leaders d’initiative qui travaillent avec les « business owners » des tribus pour construire le carnet de produits et les évolutions nécessaires à la réalisation de la stratégie.

Des arbitrages se font chaque année entre les différents portefeuilles stratégiques. Ensuite, les tribus organisent la réalisation et coordonnent les actions. Nous avons trois ou quatre « synchros à l’échelle » par an, où l’ensemble des collectifs se réajustent. Nous nous basons sur des principes forts d’agilité et de management par la confiance afin de responsabiliser l’ensemble des équipiers, quel que soit leur rôle, pour que chacun amène sa pierre à l’édifice. Les leaders de chaque feuille de route sont responsables de mener à bien les investissements, les « business owners » des tribus sont responsables de l’agencement dans leurs collectifs et les responsables de tribus s’assurent des livraisons et de la bonne coordination entre les squads produits.

Comment maintenez-vous votre patrimoine applicatif ?

Le maintien technologique à l’état de l’art, c’est quelque chose que nous avons introduit il y a maintenant cinq ans. Nous ne voulons plus de patrimoine qui traîne sans être maintenu, de versions qui ne sont pas à jour, de librairies ou de composants obsolètes sur nos plateformes.
Chaque année, notre patrimoine doit bénéficier d’un bon niveau de maintenance : mises à niveau, sécurité, correctifs…

“Aujourd’hui, il est vivant et a probablement 10 à 15 ans de cycle de vie devant lui. Je ne veux plus lancer des programmes ou projets, livrer un super produit, puis le laisser péricliter doucement pendant dix ans, alors qu’on a investi beaucoup au départ. Nous améliorons en continue les produits, tant sur le plan technique que fonctionnel, en tenant compte des feedbacks des utilisateurs. Pas des révolutions, mais des évolutions qui améliorent l’expérience. Cependant, il faut faire des choix, car nous ne pouvons pas tout faire et ça demande beaucoup de travail dans les collectifs. C’est une grosse partie de notre activité de run.

Quelle est votre politique sur le cloud ?
MAIF a une Charte Numérique publique depuis 2016, dans laquelle nous nous engageons explicitement à garantir la protection des données de nos clients. Tous nos choix découlent de cet engagement.

Nous avons construit deux datacenters où nous hébergeons tout le « cœur de réacteur » et nos bases de données clients pour garder la maîtrise de nos données.  C’est un investissement fort, un socle que nous voulons garder dans nos murs.

Quand nous utilisons le cloud, c’est plutôt pour des flux d’interaction, pour créer des parcours digitaux performants, des parcours mobiles, ou pour interagir avec des partenaires. Nous construisons des applications « stateless », ce qui signifie que les données ne sont pas stockées dans le cloud, en particulier s’il n’est pas souverain. Elles ne font qu’y transiter.
Par exemple, lorsque vous utilisez notre application mobile, vous pouvez transiter par le cloud ;
mais uniquement le temps de votre interaction.

Quelle est votre approche de la souveraineté technologique pour le cloud ?
Il y a 5 ans, nous avons choisi de travailler avec Microsoft Azure, dans un contexte où l’offre de Cloud, au sens des hyperscalers, était essentiellement américaine. Mais aujourd’hui, ce n’est plus suffisant. Nous sommes en train de réfléchir, comme d’autres grandes entreprises européennes, à nous tourner vers d’autres acteurs européens. Nous sommes en phase d’évaluation et je ne peux pas encore dire avec qui nous allons travailler.

Il y a deux ans encore, il n’y avait pas d’offre crédible à grande échelle, pas en matière d’hébergement, mais en termes de stack logiciel pour combiner les services entre eux. Nous avons désormais des véritables acteurs de cloud souverain européen en face des hyperscalers américains.

Ce que nous voulons, c’est pouvoir faire du cloud programmable dans toute sa complexité pour bénéficier d’une vraie richesse de services. Ce n’est pas juste une VM ou un « grand disque ». Ça, nous savons le faire nous-mêmes. Le vrai sujet, c’est d’avoir des fonctionnalités avancées pour développer, orchestrer, et faire tourner nos systèmes de manière fine.

Il y a aujourd’hui des acteurs qui font des technologies construites par de vrais ingénieurs européens, notamment en France. Ça change la donne. Nous espèrons intégrer cette capacité d’ici la fin de l’année, et ainsi disposer de fonctionnalités souveraines, en complément de ce que nous faisons déjà. C’est d’autant plus important avec la question de l’IA générative qui implique des traitements avec des capacités que nous ne pouvons pas forcément intégrer dans nos datacenters, à cause du coût et de la rapidité d’évolution.

Pour faire du génératif, nous aurons besoin d’infrastructures cloud, mais toujours dans des environnements dont nous pouvons garantir la souveraineté, avec un niveau de sécurité équivalent à celui de nos datacenters. Doter notre infrastructure de cette capacité nous permettra de mettre en œuvre du génératif beaucoup plus confortablement, tout en respectant pleinement nos engagements. Et ça, c’est essentiel.

Le Cigref dénonce régulièrement l’inflation des coûts services de cloud et des logiciels. Quel est votre avis sur le sujet ?
En ce qui concerne les coûts du cloud, je suis assez serein. Les acteurs américains sont en forte compétition en dehors des États-Unis, notamment en Europe, ce qui garantit des tarifs relativement stables. Pour moi, il n’y a pas de différence majeure de coût entre le cloud et un datacenter interne bien géré. C’est le seul marché, avec l’IA générative, où il y a une vraie compétition.

En revanche, là où nous sommes très concernés, c’est par les politiques commerciales des éditeurs de logiciels américains. La liste est longue…Nous faisons face à des politiques commerciales qui n’ont aucun sens, avec des augmentations tarifaires justifiées par des discours marketing, mais qui ne reflètent en réalité qu’une stratégie financière pure.
Le but ? Créer un effet de levier pour pousser les clients à migrer vers le cloud, avec de nouvelles souscriptions sur des différents périmètres. Derrière, le calcul est simple : je double, voire triple mes tarifs.  Les clients qui n’ont pas encore beaucoup investi peuvent partir facilement. Mais 70 % sont verrouillés, car il leur faudrait cinq ans pour sortir. Or, ils ont d’autres priorités et sont pris par leurs projets, alors ils restent.

Cela nous choque profondément dans le groupe MAIF : nous sommes une mutuelle, ce que nous payons est directement issu de l’argent de nos sociétaires.
Pour moi, la vraie menace aujourd’hui pour les entreprises européennes, ce n’est pas tant la souveraineté technologique au sens des infrastructure, c’est plutôt cette dépendance aux éditeurs. Nous nous faisons clairement matraquer. Parfois, c’est presque du racket, il faut le dire.

De plus, en tant qu’entreprise mutualiste, nous avons une volonté de soutenir l’économie européenne. Nos achats européens permettent de faire circuler l’argent au sein de l’écosystème européen. Nous cherchons à faire des choix responsables qui développent l’économie de notre écosystème et créent de la richesse en Europe, qui in fine bénéficie à nos clients et concitoyens. Au-delà des craintes géopolitiques, les entreprises doivent aussi faire des choix responsables pour soutenir l’économie.

Vous allez donc pousser plus loin votre stratégie d’éditeur interne ?
Oui. C’est un choix stratégique d’investir dans des hommes et des femmes qui ont les compétences ou qui peuvent les acquérir. Je préfère payer des salaires, renforcer mes équipes,
plutôt que de payer des licences tous les mois, avec la promesse floue que “ça marche tout seul”. Nous, nous ne sommes pas du tout dans cette logique de “cloud as a service magique”.

Le cloud, c’est de la technologie. Et la technologie, ça tombe en panne. Nous faisons le même métier, avec les mêmes outils. Ils ne sont ni meilleurs, ni moins bons que nous. Je pense qu’il faut vraiment démystifier ça.

Ce que nous essayons de faire, c’est de fonctionner de la même manière, parce qu’il y a beaucoup à apprendre de leurs modèles opérationnels. Une des questions que nous nous posons, c’est : « Est-ce que nous professionnalisons encore plus notre logique d’éditeur en interne ? Avec une équipe qui fabrique les logiciels, une qui les met en production et une qui les opère » On pourrait imaginer aller jusque-là.

Comment abordez-vous le sujet de l’IA générative ? Quels sont les cas d’usage que vous avez identifiés ?
Nous essayons de ne pas nous laisser emporter par la hype même si la médiatisation est très forte, dans un sens comme dans l’autre. Nous avons voulu prendre le sujet à bras-le-corps, comprendre ce que c’était, et surtout voir ce que ça pourrait changer dans nos métiers. Nous avons commencé à travailler il y a plus d’un an. À ce stade, nous avons identifié deux priorités. Notre objectif a été de les expérimenter, puis de commencer à les mettre en production.

Le premier sujet, pas très original, c’est la question du soutien à l’activité, notamment l’accès à la connaissance en langage naturel. Ces cas fonctionnent assez bien, mais ils ne sont pas simples à mettre en œuvre si on veut de la pertinence. Parce que dans toutes les entreprises, nous avons des bases de connaissances de qualité variable, souvent avec beaucoup d’historique qu’on ne nettoie quasiment jamais. Si on embarque tout ça sans tri, l’IA mélange tout et produit des résultats peu fiables.

Donc le gros enjeu de ces premiers cas d’usage, c’est l’investissement dans le toilettage des données. Et quand la donnée est propre, on a de très bons résultats. Aujourd’hui, nous avons déployé ça sur plusieurs métiers via un assistant en langage naturel mis à disposition des utilisateurs. Nous avons deux cas d’usage majeurs en production : l’assistance aux méters de la gestion de sinistres et l’assistance aux utilisateurs de la digital workplace, incluant les informations autour de la migration vers Windows 11.

Par ailleurs, nous fournissons à tous les développeurs qui le souhaitent des licences Copilot pour qu’ils puissent coder avec l’IA et voir ce que ça change au quotidien.
Ce qui est essentiel, c’est de maintenir un dialogue fort entre ce que propose l’IA et les pratiques attendues dans l’entreprise.

Aujourd’hui, les usages sont majoritairement liés au soutien à certains métiers, comme prochainement les équipes juridiques, où l’enjeu est fort, avec beaucoup de documentation et de jurisprudence, donc une forte valeur ajoutée. Au fond, notre objectif est de redonner du temps aux métiers pour qu’ils se recentrent sur leur vraie valeur ajoutée.

Quels sont vos points d’attention ?
Il y a beaucoup de questions sur la dimension énergétique et la consommation des modèles, c’est un sujet auquel nous sommes attentifs et qui prendra tout son sens pour les cas d’usages qui vont trouver leur place pérenne en production.

L’autre gros sujet, c’est l’accompagnement au changement. C’est exactement la même chose qu’on vit dans le grand public : est-ce que vous avez réussi aujourd’hui à ne plus utiliser votre moteur de recherche favori et à commencer d’abord par une IA générative ? Souvent, on se rend compte que nous sommes tellement conditionnés qu’on commence par notre moteur de recherche traditionnel puis on se dit qu’on pourrait quand même essayer l’IA. C’est la même chose dans l’entreprise : nos collègues ont tendance à aller vers leur base de connaissances. L’adoption se fait sur 6 à 12 mois, parce qu’il faut déconstruire des pratiques bien ancrées.
Les produits ne sont pas complexes, mais ils ne sont pas simples à designer. Nous sommes arrivés à la conclusion qu’il fallait vraiment un accompagnement qui vient du terrain, avec les équipes terrain.

Autre sujet : on parle aussi de technologies qui sont moins européennes. Ce qui pose une vraie préoccupation parce qu’il faut interagir avec les clients, sous différentes formes, et cela passe par la culture. La culture européenne, et plus encore la langue française, ne sont pas bien représentées dans les données d’entraînement : 99 % des données utilisées viennent des cultures anglo-saxonnes, avec leurs biais politiques ou idéologiques. Nous voulons donc soutenir et encourager des initiatives pour entraîner des modèles sur la culture européenne et les langues européennes, surtout le français, pour avoir par exemple des courriers qui reprennent nos éléments culturels au lieu d’être de simples traductions Nous y sommes très attentifs.

Photo : © Melanie Chaigneau -MAIF

The post Guillaume Rincé, CTO du Groupe MAIF : « Nous fonctionnons comme un éditeur de logiciels » appeared first on Silicon.fr.

  •  

Jamespot rachète SafeBrain pour renforcer son offre IA

Jamespot, acteur français de la Digital Workplace, annonce l’acquisition de SafeBrain, startup spécialisée dans l’intelligence artificielle sécurisée. Le montant de l’opération n’est pas communiqué.

Fondée en 2023, SafeBrain compte déjà plus de 50 clients, dont des banques, des ESN et de grandes entreprises.

 « SafeBrain, c’est un peu le “ChatGPT souverain” : des agents d’IA sur mesure, sécurisés, collaboratifs et surtout, maîtrisés par l’entreprise. Une brique essentielle pour construire une IA au service du collectif, pas en surplomb de l’humain.» détaille Alain Garnier, CEO et cofondateur de Jamespot dans un post LinkedIn.

Les équipes de SafeBrain vont rejoindre les 50 collaborateurs de Jamespot.

« Progressivement, nous allons rapprocher les deux plateformes pour offrir à terme une expérience unifiée : l’intelligence artificielle de SafeBrain viendra s’intégrer naturellement dans l’écosystème collaboratif de Jamespot.» indique Alain Garnier.

A voir : l’interview vidédo d’Alain Garnier sur Silicon à l’occasion des 20 ans de Jamespot.

The post Jamespot rachète SafeBrain pour renforcer son offre IA appeared first on Silicon.fr.

  •  

{ Tribune Expert } – Les MLOps, un maillon clef de la souveraineté

Entre les restrictions américaines sur l’export de GPU vers la Chine, les incertitudes autour de l’accès aux modèles d’IA et l’extraterritorialité du Cloud Act, la dépendance aux hyperscalers est devenue un enjeu stratégique. Quand les chaînes MLOps reposent sur une infrastructure soumise à des décisions politiques extérieures, la question n’est plus technique : elle devient géopolitique.

La bataille du cloud ne se joue plus alors seulement sur la performance, mais sur la souveraineté. Pour s’indépendantiser des modèles fournis par les hyperscalers, il est indispensable de développer des MLOps en s’appuyant sur des clouds souverains.

La dépendance aux clouds extra-territoriaux : un risque systémique

Confier ses données et ses pipelines d’IA à un fournisseur soumis à une juridiction étrangère, c’est accepter plusieurs choses : qu’un changement réglementaire bloque du jour au lendemain l’accès à une ressource critique (GPU, framework, API) ; qu’un acteur décide unilatéralement de mettre un terme au support sur site, comme Atlassian, qui a imposé une migration vers le cloud à ses clients ; que la réversibilité devienne un vœu pieux, tant les services propriétaires enferment les organisations dans des architectures verrouillées ; ou encore que les données fassent l’objet d’une exploitation tierce.

Pour les chaînes MLOps, cette dépendance se traduit par une fragilité opérationnelle, qui s’illustre par des déploiements et un monitoring tributaires de services non maîtrisés, des contraintes de conformité impossibles à garantir sur des clouds soumis à d’autres lois que le RGPD, ou encore une capacité de mise à l’échelle qui repose sur la bonne volonté de fournisseurs externes, eux-mêmes soumis à des tensions géopolitiques. En d’autres termes : bâtir ses pipelines d’IA sans maîtrise de son socle, c’est construire sur du sable.

Vers une alternative souveraine, avec l’open source et un cloud européen

La bonne nouvelle, c’est qu’une autre voie existe. A en croire le discours porté depuis toujours par les opérateurs de solutions propriétaires, cette alternative serait plus complexe à mettre en place et à maintenir. Mais à l’heure des LLMs et agents, la voie de l’open source et du souverain n’a jamais été aussi accessible et pertinente. D’autant plus dans le monde de l’intelligence artificielle, où les outils open source constituent la grande majorité de ceux utilisés en production, bien loin devant les solutions propriétaires.

Construire une suite MLOps souveraine repose sur deux piliers : en premier lieu, les outils open source, comme Kubeflow, MLflow, Feast, Kubernetes ou encore PostgreSQL, chacun spécialisé dans une mission dédiée (l’orchestration et l’industrialisation des workflows ML, la gestion des features des modèles, la construction de l’infrastructure…).
Ces briques permettent de composer une stack de base, modulaire, scalable, interopérable et pérenne. Elles ont aussi l’avantage d’être disponibles à la demande chez la plupart des opérateurs.

Le second pilier est incarné par les opérateurs souverains, qui proposent des environnements conformes au RGPD, à SecNumCloud, situés en Europe, et qui s’engagent envers la transparence et la réversibilité des services d’infrastructures. Plus qu’une suite d’outils, ils fournissent un espace de confiance sur lequel faire reposer les services. Il devient donc possible d’aménager des flux de débordements entre infrastructures privées et services cloud. L’hybridation, de son côté, apporte des capacités de reprise ou de continuité d’activité en cas d’incident, mais aussi, désormais, une résilience aux manques de disponibilités de ressources de calculs comme les GPU, et un accès à du matériel de dernière génération sans investissement en propre.

Ces deux piliers mènent à une plateforme MLOps à la fois transparente, avec un code auditable et des dépendances identifiées, maintenable grâce à l’absence de dépendances à des services propriétaires opaques, prévisible, car le coût et la scalabilité reposent sur des contrats clairs, et enfin souveraine, conservant un contrôle de bout en bout sur les données et modèles.

Un enjeu collectif

La souveraineté numérique n’est pas une posture défensive. C’est une stratégie de durabilité. Construire des chaînes MLOps souveraines, c’est garantir que les innovations en matière d’IA ne soient pas fragilisées par des décisions qui échappent aux entreprises. C’est aussi donner aux écosystèmes européens la capacité de rivaliser, non pas par la taille, mais par la résilience et la maîtrise.

Pour faire en sorte que leurs modèles d’IA ne dépendent pas de décisions prises à Washington, à Pékin, ou même à Bruxelles, les entreprises, qu’elles consomment ou fournissent ces solutions, doivent prendre conscience que l’enjeu dépasse la technique et touche à la capacité collective à innover librement et durablement.

*Alexis Gendronneau est Directeur Data & IA de NumSpot

The post { Tribune Expert } – Les MLOps, un maillon clef de la souveraineté appeared first on Silicon.fr.

  •  

Le tandem lakehouse-IA s’impose dans le branding d’Oracle

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.

Autonomous AI Database 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.

  •  

D’une Dreamforce à l’autre, comment Slack entretient la flamme de l’IA agentique

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.

  •