Face à la diversité grandissante des menaces, dont la sophistication est facilitée par l’usage de l’intelligence artificielle (phishing personnalisé, deepfakes…), les experts de la sécurité offensive continuent d’évoluer afin d’être en mesure de répliquer au mieux les attaquants.
Là où les audits traditionnels permettent de mettre en évidence des vulnérabilités et des non-conformités sur un périmètre précis, ils ne sont pas représentatifs du réalisme d’une attaque informatique ciblant une entreprise dans l’absolu : ce cadre bien défini les empêche souvent d’explorer ce que l’entreprise n’imagine pas.
Lever les œillères de la cybersécurité classique
En effet, les tests d’intrusion, les scans de vulnérabilités et autres audits de conformité sont en général effectués sur une maigre partie du SI de l’entreprise : une application web, le réseau interne d’une filiale, une chaîne de CI/CD, une entité spécifique… Ces audits « classiques » permettent aux consultants en cybersécurité de mettre en place des scénarios d’attaque connus, documentés et souvent exploitables à partir d’outils open-source. Néanmoins, ils ne permettent pas d’intégrer la totalité des facteurs impactant le niveau réel de sécurité de l’entreprise.
Par exemple, la combinaison d’éléments faibles à différents niveaux (humain, procédural et logique) peut permettre de concrétiser de lourds impacts. Et une campagne de spear phishing tirant parti d’un événement interne, couplée à un deepfake vocal, pourrait déjouer la vigilance des utilisateurs et permettre à un attaquant d’obtenir un accès initial au réseau interne depuis un poste de travail compromis. La conformité à des listes de points de contrôle ne peut malheureusement pas déjouer ce genre de scénarios. par
Un attaquant réel cherchant à nuire à une entreprise dans le cadre de la mise en place d’un ransomware ou d’espionnage industriel ne se limitera pas à un périmètre précis comme un auditeur, mais considérera plutôt les actifs de l’entreprise au global : périmètre logique externe, employés, infrastructures physiques, réseau interne…
Les audits « Red Team » ne sont pas un test technique ponctuel, c’est une simulation d’adversaire pensée dans la durée et se basant sur le threat model de la cible. Elle part d’une posture offensive : intelligence sur la menace, scénarios réalistes, exploitation de la chaîne humaine, procédurale et technique. La méthodologie combine renseignement (open source et ciblé), scénarios réalistes, exécutions contrôlées et évaluation du bruit, de la réponse et de la coordination interne.
Ce genre d’exercice a deux objectifs majeurs :
> Mettre en exergue un scénario complet illustrant la compromission d’actifs critiques (dits « trophées ») ;
> Tester les capacités de détection et de réaction de l’équipe de défense, dite « Blue Team », afin d’évaluer comment une organisation réagit lorsqu’on la met réellement sous pression, et de générer un diagnostic de résilience : combien de temps pour détecter ? Combien de temps pour bloquer ? Qui décide ? Quelles procédures limitent le champ des possibles de l’attaquant ? Quelles communications internes s’enclenchent (ou pas) ?
Pour la direction, ces enseignements sont précieux : ils transforment des hypothèses, jusque-là potentiellement non éprouvées, en données mesurables et leviers actionnables.
Un outil stratégique au service des comités de direction
La valeur d’un audit « Red Team » se mesure à son utilité stratégique : le rapport, la chaîne de compromission et la timeline fournissent à la direction des enseignements clairs, priorisés et intégrables au plan de gestion du risque : scénarios mis en évidence, vecteurs exploités, impacts simulés, points de défaillance organisationnels pointés…
La transparence et la communication interne sont essentielles : informer les parties prenantes concernés sans céder à la panique et préparer un plan de remédiation pragmatique. Idéalement, les audits « Red Team » sont suivis par des exercices « Purple Team », où les auditeurs et les équipes de sécurité échangent lors de sessions collaboratives afin de corriger les lacunes, améliorer les détections et raffiner les méthodologies d’intervention. Ce cycle continu (simuler, apprendre, corriger, vérifier) élève la posture globale face à une menace réelle.
Au-delà d’un audit technique, l’exercice « Red Team » constitue ainsi un fort levier stratégique : il transforme la cybersécurité en instrument d’anticipation pour le comité de direction, renforce la coordination entre les équipes et met l’accent sur la résilience business, et non pas seulement sur la conformité.
* Richard Disaro est consultant au sein du cabinet XMCO
Le groupe chinois est en tout cas parvenu, comme son compatriote en début d’année, à attirer l’attention avec un article scientifique qui touche à la frugalité de l’IA.
La planification de l’autoscaling descendue au niveau des tokens
DeepSeek avait causé un électrochoc en présentant des LLM entraînés avec nettement moins de ressources de calcul que les modèles référents du marché.
Du côté d’Alibaba, la logique est la même, mais sur la phase d’inférence. Elle implique un système de pooling GPU nommé Aegaeon.
En la matière, deux grandes approches sont traditionnellement mises en œuvre : le multiplexage et l’autoscaling.
Le multiplexage place plusieurs instances de modèles sur chaque GPU, avec un partage spatial ou temporel (technologie NVIDIA MPS). Le mécanisme est limité par la quantité de VRAM disponible.
La méthode autoscaling est plus « agressive ». Elle adapte le placement du modèle au fil du temps, en le chargeant depuis la mémoire de l’hôte ou depuis un support externe.
L’efficacité de l’autoscaling est limitée par le ratio de modèles actifs au sein des workloads. Or, la durée d’exécution des requêtes LLM fait qu’à tout moment, un grand nombre de modèles sont actifs, même si les invocations sont sporadiques. Lorsque toutes les instances GPU sont occupées par des modèles actifs, les nouvelles requêtes doivent attendre (on ne peut pas associer en un même lot des opérations de préremplissage et de décodage liées à des modèles différents). Dans ce contexte, réserver moins d’instances qu’il n’y a de modèles accroît le risque de compromettre le respect des SLO.
Pour dépasser cette limite, Alibaba a mis en place un mécanisme planification non au niveau des requêtes, mais des tokens. L’approche avait déjà été expérimentée en configuration monomodèle. En multi, elle est d’autant plus critique que le nombre de batchs augmente (puisqu’on ne peut, donc, pas batcher les requêtes de modèles différents).
Des partitions distinctes pour préremplissage et décodage
Aegaeon planifie en parallèle l’exécution d’une requête et l’autoscaling. Étant donné un ensemble d’instances GPU et des SLO cibles (TTFT, latence du premier token ; TBT, latence entre tokens), il choisit la tâche suivante (prefill ou décodage) pour chaque instance. Et opère éventuellement un autoscaling préemptif si une tâche planifiée utilise un autre modèle que celui actif.
Alibaba a opté pour une désagrégation des phases de préremplissage et de décodage. Il a ainsi divisé le pool GPU en deux partitions. La partie décodage utilise une planification en round-robin pondéré, censée maximiser le respect du TBT. Le prefill exploite un système de planification groupée : on réunit les requêtes qui visent un même modèle, tout en maintenant une approche « premier arrivée, premier servi » pour éviter tout privation de ressources. Les tâches sont ajoutées à un groupe existant si c’est possible. Sinon, Aegaeon en crée un et l’attache à la file d’attente la moins peuplée (chaque instance a sa file). La taille de batch est plafonnée à 1, vu la relative linéarité entre le nombre de tokens et le temps d’exécution – et du fait que de plus petits batchs réduisent les délais d’attente.
Réutiliser pour ne pas (tout) réinitialiser
Les solutions d’autoscaling préemptif tendent à se focaliser sur l’accélération du chargement du modèle. Alibaba Cloud s’est intéressé aux autres étapes de la procédure : réinitialisation du moteur, gestion de la mémoire et transferts du cache clé-valeur.
La réinitialisation du moteur est une séquence qui, à défaut d’optimisation, peut prendre des dizaines de secondes. Elle comprend notamment l’initialisation du cache clé-valeur, le chargement des poids, le profilage et l’optimisation (allocation d’espace pour le cache clé-valeur) et le démarrage d’orchestrateurs comme Ray destinés à distribuer l’exécution.
Alibaba s’est figuré que l’initialisation de ces différents composants pouvait être réutilisée de manière sûre entre modèles. Ainsi, Aegaeon n’initialise le moteur qu’une fois par instance, mettant tous les éléments en cache sauf poids et cache clé-valeur. Pour ce dernier, il exploite un pool préattribué dans la mémoire de l’hôte, évitant de devoir épingler des pages pendant l’autoscaling. L’ensemble réduit la latence de plus de 80 %.
Les événements CUDA mis à profit
La gestion mémoire est quant à elle rendue explicite. À l’appui, entre autres, d’un tampon VRAM autogéré et d’un cache clé-valeur « unifié » (chaque zone, en VRAM ou DRAM, est divisée en fragments de taille fixe qui accueillent différents blocs en fonction de la forme du cache).
Pour ce qui est des transferts du cache clé-valeur entre hôte et GPU, l’enjeu est de permettre leur chevauchement tout en minimisant les conditions de concurrence des données. Les événements CUDA ont été mis à contribution dans ce but, pour suivre individuellement les transferts.
De 1192 à 213 GPU pour le Model Studio d’Alibaba Cloud
Pour évaluer Aegaeon, Alibaba a choisi une config à deux nœuds de 8 GPU H80-80, avec 2 To de DRAM (DDR5) et 192 CPU Xeon Platinum 8469C. Il y a fait tourner des LLM de plusieurs familles (Qwen, Llama, InternLM, Yi, etc., essentiellement de 6 à 14 milliards de paramètres) sur le dataset ShareGPT et deux déclinaisons « augmentées » (inputs et outputs allongés). La comparaison a été faite avec MuxServer et ServerlessLLM, deux solutions qui adoptent respectivement le multiplexage et l’autoscaling.
Illustrant les limites du multiplexage, MuxServer a systématiquement refusé de placer plus de 2 modèles par GPU, en raison du manque de VRAM.
À un débit de 0,1 requête/seconde, Aegaeon soutient un débit utile doublé par rapport à ServerlessLLM. Il gère jusqu’à 70 modèles avec 10 instances de décodage. ServerlessLLM souffre de longs temps d’attente. ServerlessLLM+ (implémentation ad hoc ajoutant une planification Shortest Job First à partir d’un oracle fondé sur les longueurs d’output) atténue l’effet, mais la performance se dégrade inévitablement avec davantage de modèles actifs.
À 0,5 requête/s, l’écart de débit utile est de 2,5 par rapport à ServerlessLLM.
Cet écart se maintient sur les datasets « augmentés ». Et, quoique dans une moindre mesure, avec des SLO plus stricts laissant moins de marge de pooling. Cela se vérifie aussi sur des configs plus restreintes en hardware (par exemple, un nœud de 4 GPU A10). Pour Alibaba, c’est la preuve qu’Aegaeon est potentiellement applicable à un grand éventail de workloads.
Le système alimente, depuis quelques mois, le Model Studio d’Alibaba Cloud. Il fonctionne sur un cluster multirégion de 213 GPU H20 servant 47 modèles de 1,8 à 72 milliards de paramètres. Ces modèles étaient, à l’origine, servis par 1192 GPU H20. Le parc s’est donc réduit de 82 %.
Le taux d’utilisation GPU moyen (illustré ici sur une période de 70 heures) est passé à 48 % avec Aegaeon, sans violations observables de SLO.
Dans la nomenclature Cigref des métiers du SI, ne cherchez plus le chief digital officer : son profil a été supprimé.
Cette fonction relève désormais davantage d’un rôle transversal que d’un métier à part entière, nous explique-t-on. Son exercice est réparti entre plusieurs directions métiers. Lesquelles exploitent des outils numériques dont la DSI n’a pas toujours la gestion, tout en contribuant de plus en plus à la structuration de l’offre digitale destinée aux clients finaux. Quant aux produits orientés vers des clients internes, leur structure est souvent assurée par la direction du numérique.
Un autre profil a disparu d’une année à l’autre : le responsable marketing de la DSI. Constat : il n’existe pratiquement plus en tant que tel, en tout cas dans les organisations membres du groupe de travail ayant élaboré la nomenclature. Ses missions ont été réparties sur plusieurs services ou attribuées aux CIO. Dans quelques organisations, la communication est portée par un pôle plutôt que par une personne.
Dans la version 2024 de sa nomenclature*, le Cigref avait souligné que la fonction de chief digital officer pouvait être dévolue au DSI. Et que l’activité « marketing de la DSI » ne devrait pas concerner une seule personne, mais se disséminer dans l’organisation, à des niveaux différents suivant les métiers.
Le profil DevOps, envisagé l’an dernier, intégré cette année
En 2024, le Cigref avait envisagé d’intégrer le profil DevOps. Cela ne s’était pas fait, faute de consensus. Certains membres considéraient en effet que ses compétences venaient compléter des métiers existants. D’autres estimaient que la fonction pouvait être couverte en adaptant les processus et les activités des métiers IT. Il en avait été conclu que le concept même de DevOps « [cherchait] encore à se formaliser ».
La posture a évolué depuis : voilà le profil intégré à la nomenclature version 2025. Il fait généralement suite à un début de carrière en tant que développeur, administrateur systèmes et réseaux, intégrateur d’applications ou encore chargé de support de production. En fonction du niveau de séniorité, il peut être une passerelle vers des emplois d’expert SRE, d’architecture technique ou de tech lead, ou de management.
Le Cigref retient quatre indicateurs de performance pour le métier DevOps :
Pourcentrage de déploiements à l’origine des incidents
Niveau de qualité du code livré
Délai de promotion des changements
Temps moyen pour restaurer le service après un incident
Pour ce qui est des compétences nécessaires, l’association met à égal niveau (3/5) :
Déploiement de solution
Fourniture de service
Gestion des changements métier
Gestion des problèmes
Gestion des risques
Concernant les notions transversales utiles au métier DevOps :
Sécurité (4/5)
Utilisabilité (3)
Développement durable (3)
Éthique (2)
Questions juridiques liées aux TIC (2)
Respect de la vie privée (2)
Accessibilité (1)
L’UX designer, autre nouvel entrant
Un autre profil rejoint la nomenclature : l’UX designer. Il a typiquement un bac +2/+3. Une spécialisation en design, ergonomie ou psychologie cognitive est parfois demandée. Il peut ensuite devenir lead UX, product designer, head of design, etc.
Le Cigref retient, comme KPI :
Taux de conformité aux standards d’accessibilité (score d’audit RGAA)
Taux de satisfaction des utilisateurs (satisfaction client, NPS, échelle d’évaluation de l’usabilité perçue**)
Taux de parcours non terminés par l’utilisateur
Taux de conversion avant/après optimisation, taux de succès des tâches, nombres d’erreurs utilisateur
Productivité de la solution (temps mesuré sur un parcours)
Score Ecoindex de l’interface, consommation énergétique moyenne par page, empreinte carbone estimée
Pour ce qui est des compétences :
Expérience utilisateur (4)
Identification des besoins (4)
Stratégie et politique SI (4)
Conception d’application (3)
Test (3)
Déploiement de solution (3)
Et des notions transversales :
Utilisabilité (5)
Accessibilité (5)
Éthique (4)
Questions juridiques liées aux TIC (4)
Respect de la vie privée (4)
Développement durable (3)
Sécurité (1)
* En 2024, le Cigref avait aussi ajouté deux profils. D’une part, le data architect, qui reprenait les grandes lignes du profil de l’architecte d’entreprise… avec une forte coloration data. De l’autre, le product manager, découlant de l’augmentation des activités dévolues au product owner.
** Mesure la perception d’un produit ou d’un service selon le ressenti des utilisateurs, sur 3 axes : efficacité, efficience, satisfaction liée à l’interaction.
En 2027, l’ANSSI n’acceptera plus, en entrée de qualification, des produits de sécurité qui n’embarquent pas de cryptographie post-quantique.
Son directeur général Vincent Strubel l’a annoncé début octobre aux Assises de la sécurité. Sa déclaration a fait écho à une FAQ que l’agence avait publiée la veille, et où figurait cette même info.
En toile de fond, l’enrichissement du corpus de l’agence sur ce thème. Et, en parallèle, le franchissement de jalons. Entre autres, l’émission de ses premiers visas de sécurité pour des solutions comprenant de la cryptographie post-quantique. Plus précisément, des certifications CC (Critères Communs) pour la carte à puce MultiApp 5.2 Premium PQC de Thales (29 septembre) et pour le microcontrôleur S3SSE2A de Samsung (1er octobre), qui exploitent le schéma de signature ML-DSA.
Les évaluations ont été conduites par le CEA-Leti, premier centre agréé « pour la portée PQC ». D’autres centres sont en cours d’agrément : Amossys (groupe Almond), EDSI (groupe NAGRA Kudelski), Quarkslab, Serma Safety & Security, Synacktiv et Thales/CNES.
Des guides et des référentiels à actualiser
Au-delà de l’horizon 2027, la FAQ mentionne l’échéance 2030. Avec un commentaire : à ce moment-là, il « ne sera plus raisonnable » d’acheter des produits qui n’intègrent pas de cryptographie post-quantique.
L’ANSSI invite à réaliser dès à présent un travail d’inventaire : identifier les données et les cas d’usage menacés, puis les équipements qu’il faudra mettre à jour, et prendre contact avec les fournisseurs pour connaître leur roadmap.
Pour le moment, l’agence focalise ses conseils essentiellement sur les offreurs. Dans cette logique, elle prévoit de publier des recommandations techniques (intégration dans les protocoles, crypto-agilité, formation de certificats…). Et aussi d’actualiser, en 2026, son référentiel IPsec DR afin d’y intégrer les algorithmes post-quantiques*. En attendant, elle invite à consulter un guide d’aide à la transition signé du renseignement néerlandais et de deux instituts de recherche nationaux (en anglais ; 2e édition, décembre 2024).
L’ANSSI s’est aussi impliquée dans l’appel à projets « Développement de technologies innovantes critiques » du SGPI. La période de candidature a couru de novembre 2024 à avril 2025. Objectif : financer des briques technologiques en cybersécurité. Un des axes porte sur les outils d’aide à la transition post-quantique :
Automatisation de l’inventaire des biens cryptographiques (sondes réseau, analyse d’applications / binaires, gestion du cycle de vie des certificats)
Identification de biens vulnérables et priorisation des actions de migration
Innovations dans les outils d’analyse de risque
D’autres mises à jour sont prévues à court terme, comme celle du guide de sélection des algorithmes de cryptographie (actualisation prévue cette année).
Dans l’UE, la perspective d’un « niveau minimal de préparation » pour fin 2026
Dans le corpus de l’agence, le « document fondateur » reste un avis sur la migration vers la cryptographie post-quantique, publié en 2022 (et mis à jour fin 2023). Y était déjà promue l’hybridation, à savoir la combinaison avec des algorithmes de cryptographie asymétrique pré-quantique à court et moyen terme pour éviter les régressions**.
L’ANSSI codirige par ailleurs, avec ses homologues allemand et néerlandais, le groupe de travail chargé d’élaborer la roadmap de l’UE « pour la mise en œuvre coordonnée de la transition vers la cryptographie post-quantique ».
En attendant le livrable final, un premier document a été publié en juin 2025. Il est censé contribuer à l’atteinte d’un niveau minimal de préparation dans les États membres pour fin 2026. Cela induit notamment l’identification et l’implication des parties prenantes. En la matière, la France est donnée comme exemple, pour les sondages que l’ANSSI a orchestrés auprès de trois populations (fournisseurs, utilisateurs, prestataires de conseil).
Il s’agira aussi d’avoir, pour fin 2026, engagé des pilotes en vue de la transition des cas d’usage à risque « intermédiaire » et « élevé ». Par « élevé », il faut par exemple entendre, pour des données protégées avec de la cryptographie à clé publique, les cas où une compromission de la confidentialité après 10 ans ou plus causerait encore des dommages significatifs.
Une transition espérée pour 2030 sur les cas d’usage à haut risque
La catégorisation des risques dépend plus globalement d’un score, calculé à partir d’un modèle décrit dans le guide néerlandais susmentionné. Trois facteurs l’influencent :
Faiblesse de la cryptographie utilisée
Impact estimé en cas de compromission
Temps et effort nécessaires pour migrer vers le post-quantique (pour les éléments dont l’organisation responsable a le contrôle)
L’idée est que les cas d’usage à risque élevé aient migré en 2030 au plus tard (et qu’à ce même horizon, les mises à jour des logiciels et des firmwares utilisent des signatures résistantes). L’échéance 2035 est ciblée pour les cas d’usage à risque intermédiaire.
Cet agenda s’appuie en particulier sur une étude de l’ANSSI allemande (The status of quantum computer development ; dernière version publiée en janvier 2025). Il y est estimé qu’un ordinateur capable de casser la cryptographie actuelle pourrait être disponible d’ici à 2040.
Le document à l’adresse des États membres source un autre rapport, signé du Global Risk Institute. Et plus particulièrement une estimation : il y a 19 à 34 % de chances que sur la prochain décennie, un ordinateur quantique soit capable de casser RSA-2048 en 24 heures.
* Pour le moment, les produits quantum-safe ne peuvent être agréés DR s’ils doivent être conformes à un référentiel qui ne permet pas l’utilisation de tels algos.
** Les seuls algorithmes post-quantiques pour lesquels l’ANSSI ne recommande pas un recours systématique à l’hybridation sont les algorithmes de signature fondés sur le hachage : SLH-DSA, XMSS et LMS.
Si les principales entreprises technologiques américaines se donnent beaucoup de mal ( et quelques investissements) pour être dans les petits papiers de Donald Trump, elles n’en négligents pas moins le bon vieux lobbying.
Selon les déclarations obligatoires transmises au Sénat américain dans le cadre du Lobbying Disclosure Act, les dix premières ont consacré environ 90 millions $ au lobbying fédéral entre janvier et septembre 2025. Soit le troisième secteur le plus actifs, derrière la santé et la finance.
Meta en tête, l’intelligence artificielle en forte progression
Meta domine largement avec 19,6 millions $ sur la période, soit près de 20 % du budget total du secteur. Le groupe dirigé par Mark Zuckerberg a notamment défendu ses positions sur la régulation des plateformes, la modération des contenus et la législation concernant l’intelligence artificielle.
Amazon arrive en deuxième position avec 13,2 millions $, suivi d’Alphabet (Google) avec 10,3 millions. A elles trois, elles concentrent plus de 43 millions $ de dépenses de lobbying sur neuf mois.
Mais ce sont les acteurs spécialisés dans l’intelligence artificielle qui enregistrent les croissances les plus marquées. Nvidia a progressé de 0,9 million au premier trimestre à 1,9 million au troisième, pour un total de 4,1 millions $. Anthropic et OpenAI ont respectivement dépensé 2,6 et 2,2 millions $ sur la période.
Des priorités centrées sur l’IA, la concurrence et la cybersécurité
D’après les enregistrements publics du Sénat américain, les principaux sujets traités par ces entreprises incluent :
Le financement public de la recherche en intelligence artificielle
Les restrictions à l’exportation de semi-conducteurs
L’élaboration de normes éthiques et sécuritaires pour l’IA
Les projets de législation fédérale sur la protection des données personnelles
Les enquêtes antitrust menées par le Department of Justice
Les relations entre fournisseurs de cloud et agences fédérales en matière de cybersécurité
Microsoft (7 millions) et Apple (6,4 millions) maintiennent des budgets stables, privilégiant une approche institutionnelle à travers leur participation aux groupes de travail fédéraux.
Des montants appelés à augmenter
Les organisations de surveillance comme Issue One et OpenSecrets, qui compilent ces données publiques, anticipent une hausse des dépenses au quatrième trimestre 2025, particulièrement si les discussions sur un cadre législatif fédéral pour l’IA progressent au Congrès.
Ces organisations soulignent toutefois les limites de la transparence actuelle : les déclarations au Sénat ne détaillent pas la répartition des dépenses par dossier spécifique, une même ligne budgétaire pouvant couvrir plusieurs sujets distincts.
Le lobbying technologique américain s’étend également au-delà des frontières, avec des démarches parallèles menées à Bruxelles et Londres autour de l’AI Act européen et des réglementations sur la concurrence.
Montants investis dans le lobbying aux Etats-Unis par les entreprises de la Tech entre janvier et septembre 2025
Les technologies de génération audio et vidéo synthétiques, connues sous le nom de deepfakes, ont franchi un seuil critique. Longtemps limitées au divertissement sur les réseaux sociaux ou à la manipulation politique ponctuelle, elles s’imposent désormais comme des instruments à part entière dans les tactiques de cyberattaque.
Ce basculement dépasse le seul registre technologique et s’inscrit dans une transformation structurelle. La perception humaine, qu’il s’agisse d’une voix familière ou d’un visage reconnu, devient elle-même une nouvelle surface d’attaque.
Dans ce contexte, les entreprises font face à une menace qui s’appuie moins sur la technicité brute que sur la manipulation fine des comportements humains. Des campagnes de fraude exploitent aujourd’hui des voix clonées et des vidéos truquées pour simuler des communications authentiques et tromper même les collaborateurs les plus vigilants.
En février 2024, un employé d’une multinationale hongkongaise piégé par un deepfake transférait 24 millions d’euros. L’arnaque a fonctionné, car tout semblait authentique : accent, rythme, ton… La banalisation de ces outils, rendue possible par leur accessibilité économique et technique, accélère l’industrialisation de ces attaques.
Une menace technologique devenue humaine
Les activités de simulation d’attaques menées auprès d’organisations internationales montrent que le recours aux deepfakes n’est plus une hypothèse futuriste, mais une réalité bien établie. Un rapport d’Anozr Way datant de 2024 indiquait que le nombre de deepfakes pourrait passer de 500 000 en 2023 à 8 millions en 2025.
Les deepfakes exploitent une faille rarement anticipée dans les dispositifs de cybersécurité : notre confiance instinctive dans les interactions humaines. Des voix clonées servent à incarner des dirigeants ; des vidéos générées à partir de contenus publics sont intégrées dans des scénarios crédibles et scénarisés pour tromper des collaborateurs expérimentés. Plus que la sophistication technique, c’est l’industrialisation de ces pratiques qui doit alerter.
La facilité de clonage vocal, nécessitant seulement quelques dizaines de secondes d’enregistrement souvent accessibles via les médias publics tels que Youtube ou TikTok, permet de générer des voix artificielles en quelques minutes et à faible coût. Ces voix sont ensuite utilisées dans des campagnes automatisées, incluant des appels téléphoniques de masse menés par des agents conversationnels qui simulent une interaction humaine convaincante.
Ce changement de paradigme déplace le point d’entrée des attaques, du système informatique vers les comportements humains, exploitant la confiance, l’urgence et la reconnaissance vocale.
Sensibilisation, doute et vérification : les nouveaux piliers de la cybersécurité
La plupart des entreprises ont concentré leurs efforts de cybersécurité sur la protection des systèmes et des données. Or, face aux deepfakes, c’est l’humain qui devient le point d’entrée. Ces attaques exploitent une faiblesse majeure dans les dispositifs de cybersécurité actuels : l’absence de réflexes de vérification dans les communications vocales et vidéo.
Alors que la plupart des entreprises ont mis en place des campagnes de sensibilisation au phishing par email, la sensibilisation aux deepfakes reste quasi inexistante. D’autant que, contrairement au phishing, désormais bien connu, les appels ou visioconférences falsifiés restent largement sous-estimés. Le réalisme des deepfakes, notamment dans des contextes de stress ou d’urgence, brouille les signaux faibles qui pourraient alerter.
La détection repose sur des signaux subtils, comme un décalage dans les réponses ou une intonation robotique, mais ces indices sont souvent ignorés dans des contextes de stress. La mise en place de pratiques systématiques de vérification, à travers des questions contextuelles dont seules les parties légitimes connaissent la réponse, et dont la réponse peut changer régulièrement (par exemple, « Quand nous sommes-nous vus pour la dernière fois ? ») ou par des canaux secondaires de confirmation, devient essentielle. La méfiance se transforme ainsi en compétence stratégique incontournable.
Les « robocalls », aujourd’hui utilisés massivement auprès des particuliers qui reçoivent chaque jour plusieurs appels automatisés par l’intelligence artificielle, peuvent également être utilisés par des adversaires à des fins illégitimes. Ici aussi, le léger décalage dans les réponses et l’intonation demeurent des indices à identifier.
Ainsi, la sensibilisation des équipes ne peut plus se limiter à la messagerie électronique. Elle doit intégrer ces nouveaux scénarios, former à la reconnaissance des manipulations et instaurer une culture de la vérification systématique. La confiance ne doit plus être implicite, même lorsqu’elle semble naturelle.
La menace des deepfakes ne peut plus être considérée comme une curiosité technologique ou un risque de niche. Elle interroge en profondeur la manière dont les entreprises gèrent la confiance, la traçabilité des décisions et la sécurité des échanges. Il devient impératif d’intégrer ces enjeux dans la gouvernance des organisations : simulations de crise, protocoles de vérification, redondance des canaux d’information, formation continue.
Plus qu’une réponse technologique, c’est une réponse organisationnelle, cognitive et culturelle qu’il faut construire. Car face à une illusion numérique qui se fonde sur la familiarité, seule une vigilance active permet d’éviter que la prochaine attaque ne passe… par la voix du PDG.
* Benoît Jacob est Tech-lead EMEA au sein de Sophos Red Team
OpenAI adopte une approche prudente quant à l’usage d’Atlas en environnement d’entreprise.
Le groupe américain vient de lancer ce « navigateur IA » basé sur Chromium. Initialement pour les Mac Arm (Apple Silicon).
Atlas est accessible à tous les utilisateurs des abonnements ChatGPT « individuels » (Free, Plus, Pro, Go). Il l’est aussi avec les offres ChatGPT Business, Enterprise et Edu… mais en bêta. Et avec des limites qu’OpenAI énumère ouvertement.
Atlas manque encore d’une config entreprise
Parmi ces limites, il y a l’absence de garanties de résidence des données. Il n’y a pas non plus, dans l’optique de déploiements gérés, de canal de distribution spécifique, ni d’épinglage de versions.
Atlas n’entre pour le moment pas dans le périmètre des certifications SOC 2 et ISO d’OpenAI. Il n’émet par ailleurs pas de logs vers la Compliance API et n’est pas doté d’intégrations SIEM ou eDiscovery.
Certains types de données peuvent ne pas être couverts par les engagements d’isolation et de conservation associés à l’abonnement Enterprise, nous précise-t-on. Les données de navigation en fait partie. Comme celles relatives à l’activité agentique.
Sur la partie réseau, Atlas ne permet pas de définir des listes blanches d’adresses IP, ni de paramétrer le private ingress. Il n’a plus globalement pas d’allowlists et de blocklists spécifiques, ni d’ailleurs ses propres RBAC, SSO et provisionnement SCIM.
Six clés MDM sont officiellement prises en charge pour commencer :
CookiesAllowedForUrls (liste des sites autorisés à définir des cookies)
RemoteDebuggingAllowed (autorisation du débogage distant)
Beaucoup d’autres clés type Chromium devraient fonctionner. Le support officiel sera étendu quand Atlas passera en disponibilité générale sur ChatGPT Business, Enterprise et Edu.
Windows a Recall, Atlas a les « souvenirs »
Sur les abonnements Business, le navigateur est disponible par défaut dans tous les espaces de travail. Sur les abonnements Enterprise, un admin doit l’activer au préalable.
Dans l’un et l’autre cas, conformément à la politique appliquée à ChatGPT, les données de navigation ne sont pas exploitées pour entraîner les modèles d’OpenAI* (elles peuvent l’être sur les abonnements individuels ; c’est toutefois en opt-in).
Autre élément en opt-in : la mémoire. Cette fonctionnalité, diffusée sur ChatGPT à partir de septembre 2024, consiste à retenir des éléments-clés des conversations pour ensuite améliorer les résultats. OpenAI l’avait déclinée au printemps 2025 pour aider à personnaliser les résultats de recherches web.
La voilà désormais intégrée dans Atlas. Elle implique la transmission du contenu web consulté vers les serveurs d’OpenAI, où ce contenu est synthétisé, puis retransmis à Atlas pour mettre à jour ses « souvenirs ».
Les contenus web sont supprimés du serveur dès qu’ils ont été synthétisés. Les résumés le sont sous 7 jours. Les utilisateurs de macOS 26 ont la possibilité d’opter pour un traitement intégralement en local. Les « souvenirs » en eux-mêmes ne se suppriment pas, mais ils évoluent en fonction de l’historique effacé. Il est également possible de les archiver pour ne plus que ChatGPT y accède.
Atlas permet aussi de rendre des pages web « invisibles » pour ChatGPT. Cela se règle dans les paramètres ou via l’icône cadenas dans la barre d’adresse.
* Pour ce qui est de l’exploitation des conversations, notamment dans la barre latérale d’Atlas (fonction Ask ChatGPT), ce sont les paramètres de ChatGPT qui ont la priorité.
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.
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.
OpenAI a discrètement lancé un projet visant à automatiser les tâches fastidieuses des jeunes banquiers d’affaires. 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 150 dollars de l’heure 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 accès anticipé à l’IA d’OpenAI, conçue pour remplacer les tâches de base des analystes financiers.
Les analystes en banque d’investissement consacrent souvent plus de 80 heures par semaine à 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 processus de recrutement 100% automatisé
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 un modèle par semaine, en respectant des normes strictes de formatage (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 transformation numérique d’un secteur encore très manuel.
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.
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é.
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 %.
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
À 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.
À 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.
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.
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
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.
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 ?).
Connexion
Lors du 
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. »
« 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. »