Dans un an, il n’y aura plus de Quip au catalogue de Salesforce.
Les abonnements resteront actifs jusqu’à échéance, mais ne pourront pas être renouvelés après le 1er mars 2027.
Salesforce ouvre grand la porte à Slack et à Agentforce Sales. Il explique avoir décidé d’y « réimaginer les principaux cas d’usage de Quip ». Il en mentionne quatre : planification de compte, notes de réunion, documentation d’aide, rédaction collaborative.
Pour les clients concernés, une procédure en trois temps s’enclenchera au terme de l’abonnement :
Passage en lecture seule pour 90 jours ;
blocage des logins pour 30 jours ;
suppression des données, généralement sous 30 jours.
La transition ne sera pas automatique. Salesforce fournira cependant de quoi convertir des documents Quip en canevas Slack et exporter d’autres types de contenus vers des applications tierces. Il promet aussi des outils de gestion du changement.
Live Data, Live Apps… Quip, un « canevas unifié » avant Slack
Quip est le fruit d’une acquisition. Salesforce s’en était emparé à l’été 2016, pour 750 M$. Il s’agissait alors d’une application de productivité combinant les aspects communication et collaboration. Un de ses créateurs n’était autre que Bret Taylor, ancien CTO de Facebook… et futur COO, puis co-CEO de Salesforce.
La première passerelle avait été établie au niveau du SSO (connexion à Quip avec un compte Salesforce). La fonctionnalité Live Data avait suivi début 2017. Elle permit d’intégrer, dans les documents et les feuilles de calcul Quip, des données issues de Salesforce et mises à jour « en temps réel ». En parallèle, un composant Lightning fut mis à disposition pour pouvoir, dans Salesforce, rechercher, consulter et créer du contenu Quip.
Fin 2017 étaient arrivées les Live Apps. Elles permirent d’effectuer, dans Quip, des actions sur des objets issus de Salesforce (enregistrements, calendriers et kanbans pour commencer) et de services tiers (Atlassian, DocuSign, Lucidchart, New Relic…). En combinaison avec Live Data, elles concrétisaient le principe du « canevas unifié », que Salesforce promouvrait aussi plus tard avec Slack.
Et vint – l’éphémère – Salesforce Anywhere
Ces jonctions effectuées, la marque Quip for Salesforce était née début 2019. Rapidement devenue Quip for Customer 360, elle donnait accès à Quip dans les offres Sales Cloud et Service Cloud, grâce au composant Lightning en question. Au deux types de contenus initialement pris en charge – traitement de texte et du tableur – s’étaient ajoutés les diapositives (intégrées à Quip en 2018) et les salons de discussion.
Toujours en 2019, Salesforce avait établi une connexion avec Process Builder et Flow Builder. Il s’agissait d’automatiser la création de documents à partir des données du CRM. L’année suivante, Quip devenait capable de créer des slides embarquant des dashboards Einstein Analytics. Amazon, Autodesk, Cisco, DHL, HPE, Qantas et Ticketmaster faisaient alors partie de la clientèle.
Mi-2020, Quip s’était retrouvé intégré dans le package Salesforce Anywhere. La marque, adoptée en réaction au « phénomène télétravail », reprenait le coeur Customer 360. Elle y associait, entre autres, les technologies héritées d’un rachat bouclé quelques mois plus tôt : Vlocity, qui avait développé des CRM « verticaux » sur Salesforce. Elle reposait surtout sur une application mobile et de bureau – alors en bêta – censée centraliser l’expérience de travail autour des workflows Salesforce. En particulier grâce à une brique chat et visio alimentée par Amazon Chime et par une intégration avec Zoom. Quip y avait sa place en tant que couche collaborative. Tanium était aussi dans la boucle pour aider à « passer à l’échelle » le support IT.
Salesforce Anywhere allait assez rapidement disparaître des radars. Et la marque Quip, réapparaître en conséquence, en septembre 2021. Quelques semaines plus tôt, Salesforce avait bouclé l’acquisition de Slack.
Mi-janvier, la nouvelle tombait : fin 2025, Société Générale avait décommissionné SoGPT. Après plus d’un an d’exploitation, un constat s’était imposé : ce GPT interne n’avait pas pu suivre la cadence des principales solutions du marché.
Le groupe français n’était pas à l’origine de cette annonce. Il ne l’a cependant pas démentie. Son P-DG s’en est même expliqué début février. Son postulat : puisque entre opportunités et menaces, les choses ne sont « pas encore totalement claires », il convient d’utiliser les meilleurs outils disponibles.
En interne, trois grandes typologies d’usages IA « fonctionnent », a-t-il ajouté. Premièrement, le résumé et la traduction de texte. Deuxièmement, l’extraction de données « plus ou moins structurées ». Troisièmement, les tâches informatiques, à commencer par le codage. Pour tous ces aspects, Société Générale préfère recourir à une technologie externe qui a « prouvé sa fiabilité » et sa « capacité à favoriser l’adoption ».
Cette techno, c’est Copilot, de Microsoft. Elle n’est pas, et de loin, une nouvelle venue dans la boîte à outils de Société Générale. Le groupe l’avait déployée en parallèle de son GPT interne. Sa directrice de l’innovation l’évoquait déjà en septembre 2023. Elle dénombrait alors quelque 600 cas d’usage de l’IA « classique », générant environ 340 M€ de valeur.
Un an plus tard, à l’occasion de la conférence Everyday AI Paris, l’intéressée avait mentionné SoGPT. Elle recensait alors 650 « cas d’usage data », dont plus de la moitié impliquant de l’IA. Le volet génératif était abordé sous le prisme « 4C » : client, contenu, concision et code. L’objectif était de dégager une valeur globale de 500 M€ à l’horizon 2025.
SocGen AI, une entité pour porter des développements internes « lorsque pertinent »
Pour industrialiser les solutions d’IA, Société Générale a créé, en mars 2025, une entité transversale : SocGen AI. Sa présidente est Laura Mather, COO du groupe. Son DG Nicolas Méric est un ancien de DreamQuark et de Linedata, fournisseurs de solutions data/IA pour le secteur financier.
L’AG de mai 2025 avait été l’occasion de revenir sur SocGen AI. Et, notamment, de promettre une ouverture aux expertises externes. Société Générale précisait alors avoir une stratégie de fournisseurs diversifiés… et opter pour des développements internes « lorsque pertinent ».
En septembre 2025, le groupe avait porté plainte auprès de l’Organisation mondiale de la propriété intellectuelle. Sa cible : une petite entreprise britannique qui avait déposé, trois ans plus tôt, le nom de domaine socgen.ai. Il avait obtenu raison en invoquant le dépôt de la marque SOCGEN au niveau européen en 1998 puis international en 2001.
Fin novembre, des offres d’emploi mentionnaient encore SoGPT. Par exemple, pour un poste de stagiaire à Monaco. Une des missions consistait en l’accompagnement des métiers par le déploiement et le support de SoGPT… ainsi que de Copilot.
Début décembre, un média indien publiait une interview de la DRH pour la zone Asie-Pacifique. Était évoqué, en particulier, l’usage de l’IA au sein du LMS (système de gestion de la formation) et de la marketplace interne de talents. SoGPT l’était aussi, comme Copilot. L’un et l’autre aident à l’interprétation des textes de loi, expliquait la DRH. Elle parlait aussi du recours à Copilot pour synthétiser les enquêtes de satisfaction employés.
Cinq fois le mot « souveraineté » dans un même post : sur le blog d’Alibaba Cloud, c’est inhabituel, pour ne pas dire quasi inédit.
Ce post, publié début février, dresse un « bilan annuel » de l’offre de cloud privé Apsara Stack. Dans la pratique, il s’agit d’une plaquette commerciale. Elle a, donc, la particularité de comporter de nombreuses références à la notion de « souveraineté ». Avec des exemples. Parmi eux, le Sénégal. Sur place se dérouleront, du 31 octobre au 13 novembre 2026, les Jeux olympiques de la jeunesse. Les principaux SI sous-jacents doivent être migrés chez Alibaba Cloud, nous explique-t-on. Apsara Stack portera des « applications critiques » à l’image de la billetterie et de la gestion du parcours de la flamme. Il est surtout censé contribuer, par après, à la mise en place d’une « infrastructure cloud nationale souveraine »…
Alibaba Cloud donne un autre exemple : celui de l’Algérie, qui s’est appuyée sur ses services pour déployer une « infrastructure cloud souveraine pour les services publics ».
Alibaba Cloud mise sur les partenariats telcos
Pour trouver trace d’un autre emploi du mot « souveraineté » sur le blog principal de l’entreprise chinoise, il faut remonter à septembre 2025. Elle avait félicité un client et un partenaire intégrateur malaisiens qui venaient de remporter des prix d’innovation décernés par une association représentative du secteur IT.
La notion de souveraineté apparaît épisodiquement sur d’autres canaux de com d’Alibaba Cloud. Illustration sur Facebook en novembre 2025, dans le cadre d’un forum gouvernemental en Arabie saoudite. L’entreprise avait organisé un atelier à ce sujet avec Atos.
Quelques mois plus tôt, son directeur secteur public avait appelé les pays émergents à investir dans le « cloud souverain ». Il avait évoqué les alliances montées dans cette perspective avec des opérateurs télécoms. Et en avait mentionné une : en Afrique du Sud, avec BCX, qui assure une « exploitation indépendante » du cloud.
Alibaba Cloud avait fait son entrée sur le marché sud-africain grâce à ce partenariat. C’était en 2022. Promettant d’accompagner le développement de compétences locales, il a mis sur pied , avec BCX, une Alibaba Cloud Academy.
Des certifications européennes… surtout en Allemagne
Dans son trust center, Alibaba Cloud détaille sa conformité à diverses réglementations nationales… mais exclusivement sur la plaque Asie (+ Australie). Toutefois, parmi les certifications dont il dispose, certaines ont été délivrées en Europe. Notamment C5 (le « SecNumCloud allemand »), obtenu pour la première fois en 2020. L’Allemagne lui a aussi attribué l’AIC4 (AI Cloud Service Compliance Criteria Catalog), qui évalue la sécurité des services d’IA. Sur place, il en a également obtenu une de la part de l’industrie automobile : TISAX (Trusted Information Security Assessment Exchange).
En Europe, Alibaba Cloud détient par ailleurs la certification EU CoC. Elle est censée témoigner du respect des obligations de l’article 28 du RGPD, relatif aux sous-traitants.
Ce changement « marque le passage d’une vision centrée sur le SI à une approche globale du numérique », assure le Cigref.
L’association est à l’origine de ce document, élaboré avec deux pairs : l’AFAI-ISACA (Association française de l’audit et du conseil informatique ; aujourd’hui ISACA France) et l’IFACI (Institut français de l’audit et du contrôle internes).
L’intégration d’un modèle de maturité
La version initiale fut publiée en 2011. Une première mise à jour intervint en 2019, toujours sous le nom de GAGSI (guide d’audit de la gouvernance des SI). Elle avait notamment ajouté la culture de l’innovation et la gestion des données comme vecteurs d’analyse.
Le Cigref et ses pairs viennent d’en sortir une nouvelle révision. Elle aussi ajoute un axe d’analyse : la RSE. Surtout, donc, elle se focalise sur la notion de « numérique ». Et positionne les bonnes pratiques de gouvernance au niveau de l’ensemble de l’organisation – plus seulement de la DSI. D’où l’acronyme MagNUM, pour « modèle de maturité et d’audit de la gouvernance numérique ».
Des travaux antérieurs avaient ouvert la voie à cette approche. Ils avaient permis de classer les « bonnes pratiques » de chaque vecteur par niveaux de maturité.
Le MAGNum reprend ce système. Mais de façon plus fine, en l’appliquant à tous les critères composant chacune des bonnes pratiques. Les niveaux dépendent de l’effort de mise en place. Le Cigref et Cie y associent un outil de mesure, la notation consolidée devant permettre d’obtenir un « radar de maturité ».
Parallèlement à l’ajout de la RSE, l’axe « risques » s’enrichit de bonnes pratiques de conformité et met davantage d’accent sur la cybersécurité. L’IA se diffuse de surcroît dans tous les vecteurs, à commencer par celui relatif à la data.
Les lignes bougent, leur contenu aussi
Du GAGSI au MAGNum, les évolutions structurelles sont nombreuses. Le premier axe (« Stratégie ») est une bonne illustration, entre précision, fusion, division et ajout de critères.
La première bonne pratique – participation du DSI à l’élaboration de la stratégie de l’entreprise – demeure. Mais le critère de communication des résultats de la veille technologique est scindé en deux, correspondant à la mise en place du dispositif de veille et au partage des résultats.
En « version MAGNum », cette même bonne pratique a des critères supplémentaires. D’une part, décliner le plan stratégique de l’organisation sous forme de feuille de route numérique. De l’autre, assurer que les sujets de transformation numérique bénéficient d’un sponsoring au plus haut niveau de l’organisation.
Des ajouts, il y en a aussi sur la bonne pratique consistant à intégrer, dans le volet numérique du plan stratégique, les cibles métiers et technologiques ainsi que la planification des ressources nécessaires à leur atteinte. Apparaît notamment un critère appelant à décrire les paliers d’évolution vers les objectifs. En parallèle, le MAGNum fusionne le critère relatif à la stratégie de sourcing dans celui qui invite à préciser les ressources nécessaires.
Pour trouver des critères que le MAGNum précise, on peut aller voir sur la partie communication du volet numérique. La nouveauté : une exigence d’adapter cette com aux publics cibles. Autre exemple de précision : l’instance de pilotage stratégique du SI mise en place pour valider ce même volet et en effectuer le suivi. Elle le sera typiquement au niveau de la DG… mais pourra, le cas échéant, être assurée par la direction de la BU concernée.
Innovation : penser aux dispositifs de repriorisation
Les mêmes types de modifications structurelles se retrouvent sur le deuxième axe (« Innovation »). Témoin la bonne pratique relative à l’encadrement des efforts par une politique et une gouvernance adaptées. Il n’y est plus question d’une instance en charge de l’effort d’innovation, mais d’une structuration des activités, déclinable « de différentes façons plus ou moins formelles ». Le MAGNum mentionne, à ce sujet, le rapprochement entre DSI et marketing stratégique. L’ensemble n’était pas absent du GAGSI, mais figurait dans une autre bonne pratique.
Avec la disparition du critère d’existence de ladite instance, les suggestions de responsabilités associées glissent dans un autre critère (définition claire des rôles et responsabilités dans la politique d’innovation).
Du GAGSI au MAGNum, la notion de PMO (Product Management Office, censé faciliter l’innovation par les technologies émergents) disparaît aussi (elle perdure toutefois sur l’axe « Portefeuille de projets »). Tandis que la bonne pratique relative à la communication et à la performance est divisée en deux, pour couvrir séparément chacun de ces aspects.
La bonne pratique sur le traitement agile des initiatives d’innovation ne change quasiment pas. Si ce n’est qu’y apparaît la notion de dispositifs de repriorisation, dans une logique de souplesse budgétaire.
Une plus grande surface pour la protection cyber et la conformité
Le GAGSI dédiait une bonne pratique à l’identification et à la documentation des contrôles dans les applications. Avec le MAGNum, elle disparaît… pour se retrouver intégrée dans une autre, nouvelle, relative à la protection des données.
La conformité a donc désormais sa bonne pratique spécifique. Laquelle englobe, entre autres, élaboration d’une charte, compliance by design, documentation des écarts et reporting.
Même remarque pour la protection contre les cyberattaques (identification d’une fonction RSSI, définition d’une PSSI, formation et sensibilisation, tests et certifications par tiers, etc.). Et pour la protection des infrastructures numériques (redondance, politique de sauvegarde, processus de gestion de l’obsolescence et des vulnérabilités…).
Sur la partie « identification et évaluation des risques », le GAGSI avait un sous-critère SOC. Le MAGNum n’en a pas, même s’il inclut l’identification des menaces suffisamment importantes. À la place, il appelle les organisations à prendre en compte les risques impactant leur écosystème. Ainsi que l’influence de leurs propres évolutions internes.
Pour ce qui est du cadre de gestion des risques, le MAGNum mentionne, au contraire du GAGSI, l’aspect certifications professionnelles. Il précise par ailleurs la nécessité d’intégrer les risques tiers dans la cartographie. Et cite davantage de référentiels pour l’inventaire de risques (ISO 31000, EBIOS RM, COSO ERM, NIST CSF, OCTAVE et MEHARI rejoignent Risk IT Framework, COBIT et ISO 27005).
IT for green et accessibilité numérique, nouveautés dans la version 2026
L’axe RSE est plus synthétique que les précédents. Il comprend 5 bonnes pratiques :
Gouvernance Sponsorship de la DG en matière de numérique responsable, intégration de la politique RSE de l’organisation dans la stratégie numérique, instance de pilotage du numérique responsable…
Programme de sensibilisation et de formation
Référents numérique responsable dans les BU, intégration de cette dimension dans les compétences recherchées pour les candidatures IT…
Écoconception numérique
Pilotage dédié de la performance écologique du SI, actions dédiées à l’accessibilité numérique, accompagnement des métiers à l’élaboration de solutions IT for green…
Politique d’achats numériques responsables
Critères RSE explicites dans les cahiers des charges, préférence pour le matériel labellisé ou certifié RSE, challenger les fournisseurs sur la fin de vie des équipements…
La filière numérique pilote se contribution à la RSE de l’organisation
La data pour l’IA… et l’inverse
Sur la partie data, le GACSI s’articulait en cinq bonnes pratiques. Dans les grandes lignes, gestion, valorisation, sécurisation, réglementation et éthique.
Le MAGNum divise l’aspect gestion en deux bonnes pratiques. Au sein de la première, il combine les aspects cartographie et analyse de la chaîne de valeur. Dans la deuxième, il fusionne des critères de maintien d’un référentiel et d’un dictionnaire de données ainsi que de contrôle de la data quality. Il y ajoute une mention de l’IA, en tant qu’elle est utilisable pour « rendre le processus [de gestion] plus efficace ».
Une bonne pratique reste dédiée à la valorisation. Avec deux précisions. D’un, les initiatives peuvent concerner tant les données structurées que non structurées. De deux, la mesure de leur efficacité doit englober l’usage de moteurs d’IA (RAG, par exemple).
La bonne pratique « sécurisation » demeure, mais sans le critère d’intégration de la dimension data dans les PCA/PRA.
Reflet du nouvel axe RSE et du complément conformité, la réglementation et l’éthique ne font plus l’objet de bonnes pratiques dédiées. L’IA, au contraire, a désormais la sienne, entre politique d’utilisation, critères spécifiques dans le processus de décision relatifs aux investissements, actions de promotion, valorisation des compétences et feuille de route pour le passage à l’échelle.
BYOD, IA, réseaux sociaux professionnels, logiciels à usage industriel… Les derniers « flashs ingérence » de la DGSI ont souvent fait la part belle au numérique.
Le service de renseignement avait institué ce format en 2012. Il y présente brièvement des cas réels d’ingérence économique et y associe des préconisations. Le dernier en date (février 2026) évoque les risques de captation d’informations lors de déplacements à l’étranger.
Deepfakes, shadow AI… et due diligence sans vigilance
Le « flash ingérence » précédent (décembre 2025) est consacré à l’usage de l’IA dans le monde professionnel.
L’un des cas présentés est une tentative d’escroquerie par deepfake. Elle a visé le responsable d’un site industriel d’un groupe français. L’intéressé a reçu un appel visio. Son interlocuteur avait l’apparence physique et la voix du dirigeant du groupe. Il n’a cependant pas accédé à la demande qui lui a été faite de transférer des fonds dans le cadre d’un prétendu projet d’acquisition.
Les deux autres cas présentés touchent respectivement à l’usage d’IA sans autorisation et sans vérification. Le premier implique la traduction régulière de documents confidentiels à l’aide d’un outil « grand public » développé par une société étrangère, sans aval de la hiérarchie. Le second concerne le recours à un autre outil d’origine étrangère, pour de la due diligence. La société utilisatrice a systématiquement orienté ses décisions en fonction du retour fait par l’outil, sans contrôle complémentaire.
Des approches indésirables sur les réseaux sociaux professionnels
Le « flash ingérence » précédent (novembre 2025) est dédié aux approches malveillantes sur les réseaux sociaux professionnels.
La DGSI y expose le cas d’une start-up en difficulté financière évoluant dans un secteur sensible. Son dirigeant est approché par un prétendu cabinet de conseil étranger qui déclare opérer en qualité d’intermédiaire pour un fonds d’investissement. Convaincu, il lui dévoile des informations, dont un projet de conception d’un nouveau produit. Le service juridique de la start-up finit toutefois par détecter la supercherie. Ni le cabinet ni le fonds n’avait d’existence légale. Et on n’en trouvait trace dans aucune base de données de leurs pays d’origine déclarés.
Autre fausse promesse de financement : celle qui a ciblé le responsable d’un centre de recherche. Elle provenait du soi-disant chargé de com d’une célébrité internationale. Elle était d’autant plus crédible que cette célébrité avait récemment effectué des actions de soutien dans le domaine d’activité du centre – actions largement relayées sur les réseaux sociaux. La discussion n’est pas allée plus loin lorsque l’individu a demandé le règlement préalable d’une taxe locale de plusieurs milliers d’euros.
Le troisième cas exposé est celui de salariés piégés par un faux profil. L’escroc s’est d’abord fait passer pour un comptable interne, sans succès (le dirigeant avait repéré la supercherie). Il a eu plus de réussite quelques mois plus tard. Avec un autre faux profil, il est parvenu à engager des discussions avec des salariés. Dont un qui lui a révélé des infos stratégiques relatives au calendrier de développement de certaines activités de l’entreprise et à l’état de ses progrès technologiques.
Les points faibles des logiciels industriels
En octobre, il y avait eu un « flash ingérence » concernant les risques associés à l’absence de protection des logiciels à usage industriel.
La DGSI y présente le cas d’une entreprise française développant des systèmes industriels. Un de ses clients avait, avec l’aide d’une entreprise concurrente étrangère, détourné le programme embarqué et l’avait installé sur une machine tierce. Or, ni le programme ni la machine ne bénéficiaient d’une protection par brevet. L’entreprise française avait considéré qu’en déposer un aurait publiquement exposé ses inventions. Le client a justifié la démarche par des temps de livraison jugés trop longs.
Deuxième cas : celui d’une entreprise française commercialisant un logiciel à intégrer dans des machines-outils. Un client étranger, prétextant un défaut de mise à jour, a fait une sauvegarde totale des données et du programme. Ce sans respecter les procédures de l’entreprise française, qui, habituellement, se déplace pour faire elle-même la mise à jour.
En l’absence de possibilité de protection par brevet des logiciels en tant que tels, l’entreprise craint notamment une revente à un concurrent.
La DGSI mentionne aussi un cas d’exfiltration de code source non protégé, survenu dans une entreprise ayant développé un logiciel applicatif pour un secteur industriel de pointe. Deux anciens salariés, qui avaient eu accès à ce code source développé dans le cadre de leurs fonctions, avaient créé une société concurrente pour l’exploiter. Ce quand bien même leurs contrats de travail comprenaient des clauses de confidentialité et de non-concurrence.
Entre phishing et keyloggers, la DGSI n’oublie pas le « facteur humain »
Un peu plus tôt dans l’année était paru un « flash ingérence » intitulé « Le facteur humain, principal vecteur de compromission des systèmes d’information ».
Le premier cas présenté est celui d’un salarié d’une société hébergeant des données sensibles. L’intéressé a accédé à sa messagerie professionnelle à partir d’outils personnels, alors même que la charte informatique de son employeur l’interdisait. Cela a permis à des attaquants de pénétrer le SI puis d’exploiter une faille 0-day.
Autre entreprise, autre salarié, quant à lui approché sur un réseau social professionnel par un soi-disant chargé de recrutement dans un grand groupe étranger. Invité à ouvrir une pièce jointe dans un de ses e-mails, il a ouvert la porte à un virus qui a permis d’extraire des centaines de fichiers sensibles. Ainsi que des fichiers appartenant à son ancien employeur.
La DGSI y ajoute une action malveillante d’un salarié travaillant chez un prestataire d’un grand groupe industriel. Il a installé un keylogger sur une clé USB personnelle. Puis l’a mise à disposition de ses collègues en tant que support de stockage professionnel. Cela lui a permis de récupérer les identifiants des personnes qui l’avaient connectée à leur ordinateur.
Le BYOD, consultants compris
En mars 2025, la DGSI avait publié un « flash ingérence » sur les risques associés à l’utilisation d’outils numériques personnels à des fins professionnelles.
Premier cas évoqué : un salarié ayant utilisé à de multiples reprises son ordinateur personnel pour se connecter à la plate-forme commerciale de son entreprise. Sans dispositif d’anonymisation ni chiffrement des échanges. Un membre de sa famille utilisait régulièrement cet ordinateur. Qui, pendant une courte période, a eu un fonctionnement inhabituel, non expliqué. Plusieurs mois après, le RSSI de la société a constaté que l’identifiant et le mot de passe du salarié étaient sur le darkweb. Faute d’authentification forte sur la plate-forme commerciale, des tiers ont accédé à la base de données clients.
Autre cas : celui d’un consultant d’un prestataire informatique d’une société sensible. À son domicile, il s’est fait voler son ordinateur personnel. Il y avait transféré des données de la société depuis son poste de travail pro. Elles étaient stockées sans protection particulière et l’ordinateur n’était sécurisé que par un mot de passe. Le presta n’avait pas avisé la société de ce transfert de fichiers.
La DGSI mentionne aussi une entreprise qui encourageait le BYOD sans l’avoir encadré clairement. Et sans posséder de systèmes de gestion des appareils mobiles à distance. Elle n’a pas pu déterminer ce qui est arrivé au téléphone d’un salarié lors d’un contrôle aéroportuaire. Les autorités étrangères l’ont saisi, ont obtenu son déverrouillage et l’ont emporté dans une autre pièce…
Dessiner un cuboïde, créer un raccourcisseur d’URL, lire des variables dans un fichier de configuration, implémenter le code de César… Autant de tâches de programmation qui figurent au catalogue de Rosetta Code.
Le projet en réunit plus d’un millier. Il cherche à collecter des solutions dans un maximum de langages. Son dataset a servi de base à une expérimentation dont un des fondateurs de CatchMetrics (optimisation des sites web) a récemment rendu compte. L’objectif était de déterminer quels langages sont frugaux en tokens – et donc susceptibles de moins encombrer la fenêtre de contexte des agents de codage.
Les langages dynamiques (juste) devant les langages fonctionnels
Le travail de comparaison a été confié à Claude Code, à l’appui d’un portage communautaire du tokenizer de GPT-4. L’agent avait, au préalable, sélectionné 19 langages « populaires » et avait récupéré les tâches ayant des solutions dans chacun de ces langages.
L’auteur de l’expérimentation admet les limites et les biais potentiels de son approche, qu’il reconnaît dépourvue de « rigueur scientifique » (pas de communication du prompt, entre autres). Il en souligne toutefois quelques enseignements. Entre autres, la plus grande efficacité des langages dynamiques (Clojure, Julia, Ruby, Perl et Python occupent les 5 premières places). Ne pas avoir à déclarer de types explicites aide, considère-t-il.
L’intéressé s’étonne de l’efficacité de langages fonctionnels comme Haskell et F#. L’un et l’autre consomment à peine plus de tokens que les langages dynamiques. C’est sans doute dû mécanisme d’inférence de types, estime-t-il.
La frugalité des langages orientés tableaux
Ses conclusions ont fait réagir. On lui a notamment rappelé les garanties qu’apportent les annotations de type… et le coût – en efforts comme en tokens – nécessaire pour en apporter de comparables dans les langages à typage dynamique.
On lui a aussi suggéré de tester des langages orientés tableaux. Ce qu’il a fait, avec APL et J.
APL se classe au 4e rang, consommant 110 tokens en moyenne. Sa syntaxe concise est un plus. Au contraire de son jeu de caractères, riche en glyphes (⍳, ⍴, ⌽…) auxquels le tokenizer est mal adapté.
Limité à de l’ASCII, J se révèle plus frugal, descendant à 70 tokens de moyenne.
L’expérience a ses limites en ce qu’elle se focalise sur de petites tâches. De même, le tokenizer est fixe, alors qu’on pourrait le réentraîner pour mieux gérer le code. L’auteur ne dit pas ailleurs pas si son comparatif a pris en compte les éventuelles erreurs à l’exécution et les tokens qu’elles ont consommés. Il n’aborde pas non plus les spécificités syntaxiques des langages. Par exemple, le fait que certains intègrent du code de formatage de texte dans des chaînes littérales comptées comme des tokens, tandis que d’autres ont un usage important des espaces – on peut citer les indentations de blocs dans Python – quant à eux possiblement pas comptés comme des tokens.
À l’heure où les infrastructures deviennent de plus en plus éphémères et complexes, les méthodes de monitoring traditionnelles atteignent leurs limites. De l’émergence de l’eBPF, qui permet une visibilité profonde et sans agent au cœur du noyau Linux, à l’adaptation de l’observabilité pour le Serverless, les entreprises basculent vers un modèle « as-Code ».
Cette convergence technologique ne se contente plus de surveiller la disponibilité des services ; elle intègre la donnée de performance dès la conception logicielle (Observability-as-Code), transformant l’infrastructure invisible en un système transparent, automatisé et hautement résilient.
eBPF : Le « super-pouvoir » du noyau
Cet article sur l’eBPF (Extended Berkeley Packet Filter) explique comment cette technologie révolutionne le DevOps. Traditionnellement, pour surveiller un système, il fallait modifier le code de l’application ou charger des modules noyau risqués.
> Le concept : eBPF permet d’exécuter des programmes directement dans le noyau Linux de manière sécurisée, sans changer une seule ligne de code applicatif.
> L’avantage DevOps : Une visibilité totale sur le réseau, la sécurité et les performances avec un impact quasi nul sur les ressources. C’est la fin des agents « lourds » qui ralentissent les serveurs.
Cet article traite de la complexité du Serverless (comme AWS Lambda). Puisque vous ne gérez plus le serveur, vous perdez l’accès aux métriques matérielles classiques.
> Le problème : Les fonctions sont éphémères (elles apparaissent et disparaissent en quelques millisecondes). Les outils de monitoring classiques sont souvent trop lents pour les capturer.
> La solution : Le traçage distribué. L’accent est mis sur le suivi de la requête à travers tous les services plutôt que sur la santé d’un serveur spécifique.
Cet article prône l’intégration de l’observabilité directement dans le cycle de développement, au même titre que l’Infrastructure-as-Code (Terraform, CloudFormation).
> L’idée : Au lieu de configurer manuellement des alertes et des tableaux de bord après le déploiement, vous les définissez dans votre code YAML ou JSON.
> L’objectif : Garantir que chaque nouveau microservice est « né » avec ses propres outils de mesure, évitant ainsi les angles morts lors des mises en production rapides.
Peur de la perte d’historique et du conflit de versions, risque de rupture de la chaîne si quelqu’un télécharge… Autant d’éléments qui peuvent expliquer le recul de la collaboration sur fichiers.
L’OICN (Observatoire de l’infobésité et de la collaboration numérique) contextualise ainsi ce phénomène qu’il a lui-même constaté entre les deux dernières itérations de son référentiel annuel.
Le collectif est né en 2023, sous l’impulsion de Mailoop et de Mazars. Objectif : étudier les impacts sociaux, organisationnels et environnementaux de la surcharge informationnelle. Il réunit aujourd’hui des membres d’organisations comme le Groupe ADP, Dalkia, La Poste, Orange, la CNAF, la Région Normandie et la Ville de Paris.
Beaucoup de conservation, peu de collaboration
L’OICN a publié jusque-là trois éditions de son référentiel, centré sur les usages numériques en milieu professionnel. La dernière se fonde sur l’analyse de métadonnées de 190 millions d’e-mails et de 3 millions de réunions. Elle englobe 17 000 personnes (78 % de collaborateurs, 16 % de managers, 6 % de dirigeants, avec autant d’organisations du public que du privé).
La collaboration sur fichiers reste assez occasionnelle. Sur l’ensemble de l’échantillon, 23 % n’y ont pas recours. Ils ne sont que 1 % à s’y livrer au moins une fois par semaine. Pour la plupart (58 %), c’est moins d’un fois par mois.
Pour autant, la tendance est à converser de nombreux fichiers inutiles : 46 % de ceux stockés n’ont pas été ouverts au cours des 6 derniers mois. L’OICN l’explique, entre autres, par :
Illusion du stockage illimité et infini
Messagerie électronique vue comme une « mémoire professionnelle »
Difficulté à considérer l’information comme périssable
Un collaborateur conserve en moyenne 13 138 e-mails et 2308 fichiers dans le cloud ; un manager, 26 728 e-mails et 5338 fichiers ; un dirigeant, 44 579 e-mails et 13 028 fichiers.
Un usage anecdotique des groupes collaboratifs
L’usage des groupes collaboratifs – type équipes Teams – est encore plus occasionnel. 68 % des collaborateurs ne les utilisent pas, ainsi que 57 % des dirigeants et 52 % des managers. En moyenne, on y poste 2,4 messages par semaine (2,5 pour les collaborateurs, 2,4 pour les managers, 2,1 pour les dirigeants). La quasi-totalité (96 %) sont postés par 10 % des utilisateurs. L’OICN y voit le reflet d’une difficulté à partager de l’information horizontalement sans en conserver le contrôle.
Mis dans la balance avec les e-mails et le chat, ces groupes concentrent une part négligeable du volume de messages envoyés dans les organisations qui ont des outils collaboratifs. En l’occurrence, 0,2 % chez les collaborateurs, 0,1 % chez les managers et moins chez les dirigeants.
Le chat concentre près des trois quarts des messages envoyés (74 %). En un an, le volume a presque doublé (+ 90 %), contrastant avec le recul de l’e-mail (- 57 % de messages).
Le taux d’usage hebdomadaire du chat atteint 71% chez les managers, contre 65 % chez les collaborateurs et 55 % chez les dirigeants. Pour ces derniers, la communication passe toutefois encore majoritairement par l’e-mail (84 %). Même constat chez les managers (52 %), mais pas chez les collaborateurs (38 %).
Réunions : les « tunnels », pas si rares
D’une année à l’autre, le nombre d’e-mails envoyés a diminué. Tandis que le nombre de destinataires et d’e-mails reçus a augmenté. Le développement du distanciel engendre un besoin de traces écrites, déclare l’OICN à ce sujet.
La majorité des dirigeants (72 %) ne passent pas une semaine sans envoyer d’e-mails. Il en va de même pour 52 % des managers et 24 % des collaborateurs.
La part des e-mails envoyés hors de la plage 9 heures – 18 heures va de 14 % pour les collaborateurs à 27 % chez les dirigeants.
Les « tunnels de réunions » (plus de 6 heures dans une journée) arrivent en moyenne 9 fois par an pour les collaborateurs. 20 fois pour les managers, 41 fois pour les dirigeants. À ces niveaux hiérarchiques respectifs, la participation à des réunions consomme environ 6 heures, 12 h 30 et 18 h 30.
On l’a appris il y a quelques jours : OpenAI a bouclé la plus grande levée de fonds de son histoire, à 110 Md$.
Si NVIDIA et SoftBank ont chacun mis 30 milliards, la plus grosse contribution provient d’AWS. Ce dernier a débloqué 50 milliards. Il en injecte 15 pour commencer et prévoit d’octroyer le reste « dans les prochains mois, sous certaines conditions ».
Parallèlement à cet apport financier, OpenAI promet de dépenser 100 Md$ supplémentaires au cours des 8 prochaines années en ressources de calcul chez AWS*. Un engagement qui s’ajoute à un accord à 38 Md$ signé en novembre 2025.
La perspective d’un runtime « spécial AWS »
L’alliance ne s’arrête pas au compute. AWS sera aussi le « distributeur cloud tiers exclusif » pour Frontier, la couche d’orchestration agentique qu’OpenAI a présentée début février.
Les deux entreprises entendent aussi lancer, « dans les prochains mois », un runtime agentique reposant sur les modèles OpenAI et optimisé pour l’infra AWS (natif à Amazon Bedrock). Elles n’en disent pas beaucoup plus, sinon que cet environnement permettra de conserver le contexte (mémoire, identités, outils…), évitant ainsi une orchestration manuelle.
Le partenariat implique également la conception de modèles personnalisés pour les développeurs d’Amazon. En toile de fond, des LLM maison qui ne font pas l’unanimité en interne.
* AWS parle de consommer 2 GW de capacité Trainium. En novembre 2025, il évoquait l’accès à « des centaines de milliers » de GPU. Et une possibilité d’extension à « des dizaines de millions » de CPU. L’annonce mentionnait les configurations UltraServer dotées en GB200 et GB300.
18 mois pour industrialiser l’audit de confidentialité des LLM : tel était l’objectif de PANAME (Privacy Auditing of AI Models) à son démarrage en juin 2025.
L’ANSSI, la CNIL, le PEReN et le PEPR Cybersécurité portent le projet. Il doit en résulter une bibliothèque logicielle qui unifiera cette évaluation.
Aux dernières nouvelles, le calendrier initial tient toujours : il est question de publier cette bibliothèque à l’automne 2026. En attendant, un appel à manifestation d’intérêt est lancé en vue d’une phase de test. Il court jusqu’au 28 mars. Sont concernées les « entreprises, startups [sic], laboratoires de recherche et institutions » utilisant ou développant des modèles d’IA et basés dans l’UE.
En toile de fond, un avis du CEPD (Contrôleur européen de la protection des données) selon lequel le RGPD s’applique dans de nombreux cas aux modèles d’IA entraînés sur des données personnelles, en raison de leurs capacités de mémorisation. Dans ce contexte, pour conclure au caractère anonyme d’un modèle et ainsi le sortir du champ d’application du règlement, il est très souvent nécessaire de démontrer sa résistance à des attaques en confidentialité.
Trois grandes typologies d’attaques
Les porteurs de PANAME divisent ces attaques en trois catégories. La plus fondamentale est dite « par inférence d’appartenance ». Elle vise à savoir si les données concernant tel individu ont été utilisées pour entraîner tel modèle. On peut s’appuyer sur les scores de confiance (vecteurs de probabilité) que fournissent la plupart des modèles de classification. Puis passer par des modèles proxy (shadow models). L’attaquant entraîne ces derniers sur ses propres données, puis observe comment ils réagissent face à celles incluses (réponse A) et celles exclues (réponse B).Il entraîne ensuite un classifieur d’attaque : une IA qui reconnaît si le comportement du modèle cible ressemble au « A » ou au « B ».
Il existe aussi des attaques par inférence d’attribut. Elles peuvent permettre de récupérer des attributs sensibles lorsqu’on dispose déjà d’une connaissance partielle des données individuelles utilisées pour l’entraînement. Pour cela, le modèle est utilisé comme un oracle, en se basant sur le fait qu’il encode des corrélations fines entre les données d’entraînement. On l’interroge de manière itérative pour tester toutes les valeurs possibles des attributs en question.
Troisième grande catégorie : les attaques par reconstruction. C’est la technique la plus sophistiquée si le modèle cible n’est pas génératif. Avec elle, on régénère une approximation de la donnée brute.
La CNIL donne l’exemple d’une reconstruction de visage. L’attaquant commence par une image composée de « bruit » (pixels gris aléatoires). Il le soumet au modèle. Celui-ci fournit un gradient, indiquant la manière dont on peut l’augmenter (éclaircir tels pixels, assombrir tels autres…). L’attaquant la modifie en conséquence, la soumet à nouveau, et ainsi de suite. Jusqu’à obtenir une reconstruction visuelle, « souvent floue mais identifiable ».
La première phase de tests pour PANAME doit se terminer en juin. Une seconde s’enclenchera ensuite éventuellement avec les « testeurs référents ayant été le plus impliqués dans la première phase ».
Ce n’est pas le Yoga Book 9i, mais ça y ressemble.
Plusieurs prototypes de PC portables Lenovo présentés au MWC 2026 inspirent la remarque.
Parmi eux, il y a le Yoga Book Pro 3D. Orienté création, il reprend le double écran installé depuis quelques générations sur les Yoga Book 9i… et y ajoute la 3D autostéréoscopique (sans lunettes). Le panneau supérieur (16:10, 3,2K) affiche le contenu, éventuellement converti à la volée (2D -> 3D) et avec lequel la caméra permet d’interagir (contrôle gestuel). Le panneau inférieur peut basculer entre les modes clavier virtuel et palette graphique. On peut y aimanter des « snap-on pads », accessoires physiques qui font apparaître des menus contextuels (ajustement de la luminosité, du ton…). Le PC, en Core Ultra 7 avec jusqu’à 64 Go de RAM (soudée), embarque une RTX 5070. Il pèse 2,7 kg.
Avec la dernière génération du Yoga Book 9i, le deuxième écran a gagné en modularité. Lenovo reprend l’approche avec le ThinkBook Modular AI PC, en y ajoutant un système de ports interchangeables (USB-A, USB-C, HDMI) fondé sur des connecteurs magnétiques. On reste sur des panneaux de 14 pouces (16:10, 3,8K), avec du Core Ultra 7 255H (Arrow Lake) et 32 Go de RAM. Le PC pèse 1,15 kg en mono-écran ; 1,41 kg avec le deuxième.
La Legion Go Fold est avant tout une console portable, dotée d’un écran 7,7 pouces extensible à 11,6, avec manettes détachables, en Core Ultra 7 258V (Lunar Lake) avec 32 Go de RAM. Mais elle a un mode desktop, avec clavier sans fil. Acer avait présenté le même type d’appareil au CES 2025 (la Nitro Blaze 11), mais ne l’a pas commercialisé jusque-là.
Au CES 2026, de l’écran extensible sous toutes ses coutures
Au CES 2026, on avait eu droit au ThinkPad Rollable XD. Son écran 13,3 pouces s’étire verticalement à 15,9 pouces. La partie supérieure a la particularité de s’enrouler sur l’arrière du châssis, permettant d’afficher une petite surface tactile sur la coque extérieure.
Autre machine présentée au CES 2026 : le Legion Pro Rollable. Ce laptopgaming est basé sur le Legion Pro 7i, avec Core Ultra et GeForce RTX 5090. Il a un écran 16 pouces qui s’étend horizontalement, à 24 pouces. Avec une option intermédiaire à 21,5 pouces censée aider à travailler la vision périphérique.
Du pliable, du 3D, du rotatif…
À l’automne 2025, lors de son Innovation World, Lenovo avait présenté le ThinkBook Vertiflex. Avec un écran (14 pouces) non pas extensible, mais rotatif, entre paysage et portrait. La machine pèse 1,39 kg pour 18 mm d’épaisseur.
De l’écran extensible, il y en avait eu au MWC 2025, avec le ThinkBook Flip AI PC. Son panneau 13,1 pouces peut s’étendre verticalement, à 18,1 pouces (3:4, 2000 x 2664). Il peut aussi se replier sur le dos de l’écran principal, donnant une tablette 12,9 pouces. Un élément qui le différencie du ThinkBook Plus Gen 6, que Lenovo vend à partir de 3999 € TTC.
Le MWC 2025 avait aussi donné lieu à la présentation d’un PC portable avec écran autostéréoscopique : le ThinkBook 3D Laptop. Lenovo avait également annoncé un prototype doté d’un panneau solaire : le Yoga Solar PC. Promesse : un rendement de 24 % pour – en conditions optimales – récupérer 1 heure de lecture vidéo – locale, 1080p – en 20 minutes.
Du transparent, du motorisé et de l’encre électronique
L’Innovation Day 2024 avait donné lieu à la présentation de l’Auto Twist AI PC (Core Ultra 7, 32 Go de RAM, 1,27 kg). Son signe particulier : un écran motorisé (13,3 pouces, 2880 x 1800) pivotant automatiquement pour suivre l’utilisateur. Et des commandes en langage naturel pour basculer entre les modes laptop et tablette.
Au MWC 2024, il y eut le ThinkBook Transparent Display Laptop. La technologie Micro-LED permet de faire varier la transparence de l’écran 13,7 pouces (720p). Comme celle de la zone clavier (tactile), qui peut basculer en mode tablette graphique.
Au CES 2024, Lenovo avait présenté le ThinkBook 13xGen4 SPE. Ce 13 pouces (3:2, Core Ultra, 32 Go de RAM) a un écran e-ink couleur au dos. Il sert à personnaliser le look de la machine. Vu sa faible consommation d’énergie, il peut rester allumé en permanence.
Pour la France, pas de chiffres sur l’identification électronique : c’est confidentiel.
Le vide saute aux yeux dans la présentation qu’Eurostat fait des indicateurs de progrès vers les objectifs de la « décennie numérique ».
Fin 2022, l’UE formalisait ces objectifs – et le programme d’action qui va avec – sur quatre axes : infrastructures, compétences, digitalisation des entreprises, numérisation des services publics. Elle entend les atteindre à l’horizon 2030.
Parmi les objectifs, 80 % de citoyens de 16 à 74 ans ayant recours à l’identification électronique (eID). Eurostat l’analyse sur plusieurs dimensions, en distinguant notamment l’accès aux services publics et à ceux proposés par le secteur privé.
La France est le seul État membre de l’UE à ne pas avoir de chiffres pour 2023. Elle en a en revanche pour 2025. Résultat : près de 88 % des 16-74 ans ont utilisé l’eID sur les 12 derniers mois pour accéder à des services en ligne (84 % pour des services du public ; 59 % pour des services du privé).
La France au niveau de l’UE sur les compétences numériques de base
En parallèle des trajectoires idéales pour atteindre les objectifs du programme, l’UE effectue des projections à partir des données historiques. Elles ne sont pas toutes à la hauteur des ambitions. Par exemple concernant la diffusion des compétences numériques « élémentaires » au sein de la population. Y sont inclus, dans les grandes lignes :
Recherche et vérification d’informations
Communication et collaboration (e-mail, appels audio/vidéo, messagerie instantanée, réseaux sociaux…)
Création de contenu (traitement de texte, tableur, édition multimédia)
Gestion des données personnelles (cookies, partage de localisation, visibilité en ligne…)
Résolution de problèmes (télécharger et paramétrer des logiciels, consulter ses comptes, chercher un emploi…)
En 2023, le taux d’acquisition de ces compétences « élémentaires » atteignait 60 % en France (64 % chez les hommes, 57 % chez les femmes). C’était un peu plus que dans l’ensemble de l’UE (56 % ; 57 % des hommes et 54 % des femmes).
D’après les données de 2015 à 2023, l’UE atteindrait 60 % à l’horizon 2030, loin de son objectif de 80 %.
20 millions de spécialistes des TIC : l’UE s’en éloigne
Autre objectif qui, à ce rythme, pourrait ne pas être atteint : les 20 millions de 16-74 ans employés en tant que spécialistes des TIC. Ce quand bien même la définition est large, sur la base de la classification ISCO-08.
En 2024, la France en était à 1,4 million (80 % d’hommes), soit 4,8 % de ses emplois. L’UE, à 10,3 millions (même proportion d’hommes), soit environ 5 % de ses emplois. Les taux de féminisation les plus élevés – entre 25 et 30 % – sont en Estonie, en Roumanie, en Bulgarie et en Lettonie.
La projection à partir de l’historique 2011-2024 donne 12,4 millions de spécialistes des TIC à l’horizon 2030.
La France en nette avance sur « l’objectif gigabit »
Les choses sont plus avancées sur le taux de foyers couverts par une connectivité gigabit. En France, en 2024, le taux d’abonnements fixes atteignant ce débit s’élevait à 59 %, contre 22 % dans l’UE. La couverture FTTP (FTTH + FTTB) avoisinait 87 % en France et 70 % dans l’UE.
D’après les données 2019-2024, le taux de connectivité gigabit dans l’UE atteindrait 95 % en 2030, s’approchant de l’objectif de 100 %.
Ce même objectif a été fixé pour le taux de zones habitées couvertes par au moins un réseau 5G. Lui serait effectivement atteint (France et UE en étaient déjà à plus de 94 % en 2024).
Pour les licornes, retour jusqu’en 1991
Certains indicateurs ont une valeur absolue. L’UE vise par exemple 10 000 nœuds de calcul périphériques (edge) d’une latence de 20 ms ou moins. Elle pourrait les atteindre, d’après la progression enregistrée entre 2022 à 2024 (cette année-là, la France en comptait 532 ; l’UE, 2257).
Autre objectif à valeur absolue : avoir 1 ordinateur ou simulateur quantique opérationnel. Il a été atteint en 2024. L’UE table, au rythme actuel, sur 5 machines à l’horizon 2030.
Ce pourrait être plus juste concernant le nombre de licornes. L’UE y range les entreprises créées après le 31 décembre 1990 et qui ont fait l’objet d’une introduction en Bourse ou d’une vente commerciale > 1 Md$. Ainsi que celles valorisées > 1 Md$ lors de leur dernier cycle de financement de capital-risque privé. En 2023, la France en comptait 48. L’UE, 286. Elle est partie pour atteindre les 412 (l’objectif étant de 500) si on extrapole l’historique 2008-2024.
Cloud, IA, analytics : trois options pour un objectif
Les choses sont également incertaines pour l’objectif de 75 % d’entreprises utilisant le cloud, l’IA ou l’analyse de données. La France vise moins haut, cherchant à atteindre les 65 %. Elle en était à 44,9 % en 2023.
Par « utiliser le cloud », il faut entendre au moins un service entre logiciels de finance/compta, ERP, CRM, solutions de sécurité, hébergement de bases de données et environnements de développement, test ou déploiement d’applications. En 2023, la France en était à 23 %.
D’après les données 2014-2023, 64 % des entreprises de l’UE seraient dans les clous en 2030.
La catégorie « IA » comprend text mining, reconnaissance vocale, génération de langage naturel, traitement d’images, machine learning pour l’analyse de données, automatisation de processus et systèmes robotisés. En 2024, la France en était à 10 %, contre 13,5 % pour l’UE.
D’après les données 2021-2024, le taux de pénétration dans l’UE atteindrait 36 % en 2030.
L’aspect data analytics a remplacé le big data, inscrit dans les objectifs initiaux. En 2023, il était installé dans 34 % des entreprises en France.
Selon les données 2016-2023, il le serait dans 50 % des entreprises de l’UE à l’horizon 2030.
Pour le moment, les données du secteur public font partie des sources les moins exploitées. Elles le sont en l’occurrence par 6 % des entreprises pratiquant le data analytics, quand 21 % exploitent celles relatives aux transactions commerciales et 14 % celles qui concernent les clients.
Digitalisation des PME : la France en retrait sur plusieurs dimensions
L’UE s’est aussi donné un objectif de 90 % de PME (10-249 salariés) ayant un niveau minimum d’intensité numérique. C’est-à-dire utilisant au moins 4 des 12 technologies de (cf. notre article à ce sujet). En 2024, la France affichait un taux de 68,5 %, contre 73 % pour l’UE. Laquelle n’atteindrait cependant pas son objectif, d’après les projections à partir des données 2021-2024.
Quelques chiffres sur la digitalisation des PME :
Utilisation d’ERP : 46 % en France, 42 % dans l’UE (2023)
Utilisation d’au moins deux « médias sociaux » (réseaux sociaux, (micro)blogs, wikis…) : 28 % en France, 31 % dans l’UE (2023)
Exploitation des services cloud susmentionnés : 22 % en France, 38 % dans l’UE (2023)
Recours à l’IA telle que susdéfinie : 9 % en France, 13 % dans l’UE (2024)
Usage de la facturation électronique : 30 % en France, 39 % dans l’UE (2024)
Les démarches administratives, moins numérisées qu’à l’échelle de l’UE
Il paraît difficile d’atteindre l’objectif de 100 % des démarches administratives réalisables en ligne, mais l’UE semble pouvoir s’en rapprocher. Autant pour celles qui concernent les « grands événements de la vie » (famille, carrière, études, santé, transport, déménagement, règlement de petits litiges) que pour celles qui touchent à la création et à la gestion d’entreprise.
Pour les premières, la France en était à 71 % en 2024. L’UE en était à 82 % et pourrait, sur la base 2013-2024, atteindre les 92 % en 2030.
Pour les secondes, la France en était à 77 %. L’UE, à 86 %, avec une dynamique qui pourrait permettre d’atteindre 93 % (historique 2013-2024).
La « digitalisation des entreprises », c’est quoi au juste ?
Depuis 2015, Eurostat compile un indicateur composite dit « index d’intensité numérique ». L’Union européenne l’exploite dans le cadre de son programme d’action pour la décennie numérique.
Ce programme fut formellement établi en décembre 2022. Il définit des objectifs de transformation numérique à l’horizon 2030, dans 4 domaines : connectivité, compétences numériques, digitalisation des entreprises, digitalisation des services publics.
Le mécanisme de suivi de la progression des États membres se fonde sur une quinzaine de KPI. Dont le pourcentage de PME utilisant au moins 4 des 12 technologies qu’englobe l’index d’Eurostat.
L’UE ne liste pas ces technologies et pour cause : d’année en année, la composition de l’index évolue. La dernière incarnation comprend :
Au moins 50 % des employés ont accès à Internet pour un usage professionnel
Connexion Internet à au moins 30 Mbit/s descendants
Au moins 1 % du CA en e-commerce
Au moins 1 % des ventes réalisées sur le web avec au moins 10 % en B2C
Achat de services cloud
Achat de services cloud « sophistiqués » ou « intermédiaires »
Avoir un site web
Utiliser au moins un réseau social
Faire de l’analyse de données, y compris via un prestataire externe
Utiliser au moins une technologie d’IA
Utiliser un ERP
Utiliser un CRM
Chaque dimension a ses spécificités. Pour le e-commerce, par exemple, on tient compte des achats avec paiement hors ligne. Comme « technologie d’IA », on entend autant les chatbots de service client que le big data à base de machine learning, entre autres.
La sécurité informatique est sortie du radar
Entre 2015 et 2025, les trois premiers sous-indicateurs (accès à Internet, bande passante, e-commence) n’ont pas changé.
Le critère « 1 % de ventes sur le web et au moins 10 % en B2C » n’entrait pas dans l’index en 2018 et 2020. À la place était la pratique du big data sur des données internes ou externes.
Le critère « achat de services cloud » n’a pas toujours été présent, en tout cas sous cette forme. De 2015 à 2020, Eurostat a mesuré le taux d’entreprises fournissant des « appareils portables à connexion Internet mobile » (précision en 2018 et 2019 : réseau cellulaire) à au moins 20 % de leurs employés. En 2022 et 2024, il s’est intéressé à celles qui documentaient leurs mesures, pratiques ou procédures de sécurité informatique.
De 2015 à 2018, ainsi qu’en 2020, le sixième sous-indicateur n’était pas l’achat de services cloud « sophistiqués » ou « intermédiaires », mais le fait d’avoir un site web proposant au moins une des fonctionnalités suivantes :
Description de biens et de services
Affichage de prix
Possibilité pour le visiteur de personnaliser ou de concevoir des biens et services
Suivi de commandes
Personnalisation du contenu du site pour les visiteurs réguliers
En 2019, 2022 et 2024, pour ce même sous-indicateur, Eurostat a mesuré le taux d’entreprises informant les employés de leurs obligations en matière de sécurité informatique.
À la place du critère « avoir un site web », il y eut, en 2019, 2022 et 2024, « recourir à au moins 3 mesures de sécurité informatique ». En 2021 et 2023, « utiliser au moins deux réseaux sociaux ».
Quand l’IoT, l’impression 3D, la robotique et la pub en ligne étaient des critères
En 2018, il ne s’agissait pas d’utiliser au moins un réseau social, mais d’avoir un site ayant des liens ou des références aux profils sociaux de l’entreprise. En 2020, il s’agissait d’utiliser l’impression 3D. Et en 2022 et 2024, de dispenser au personnel des formations en informatique.
Historiquement, le neuvième sous-indicateur a souvent porté sur l’emploi de spécialistes des TIC (2017, 2018, 2020, 2022, 2024). En 2015 et 2016 aussi, mais avec une option de plus : recourir à des fonctions TIC réalisées principalement par des prestataires externes. En 2019, il fallait utiliser les réseaux sociaux à au moins deux fins. Et en 2021, utiliser l’IoT.
Le sous-indicateur « utiliser au moins une technologie d’IA » est tout nouveau. En 2015 et 2017, Eurostat s’était penché sur les entreprises qui partageaient des données « relatives à la gestion de la supply chain » par voie électronique avec clients ou fournisseurs. En 2016 et 2018, à celles qui achetaient de la pub sur Internet. Et en 2019, à celles qui réalisent des ventes en ligne dans d’autres pays de l’UE. En 2020 et 2022, les entreprises étaient évaluées sur leur utilisation de robots industriels ou de service.
La facturation électronique, indicateur pendant un temps
« Utiliser un ERP » a été présent par intermittence. En 2016, il fallait pratiquer la facturation électronique. En 2018 et 2020, acheter des services cloud de niveau « intermédiaire ou élevé » (« medium-high »). Les versions 2022 et 2024 analysaient la fourniture, aux employés, d’un accès distant à la messagerie électronique, aux documents ou aux applications.
Même présence par intermittence pour « utiliser un CRM ». En 2016, ce sous-indicateur était réservé aux services cloud medium-high. En 2018 et 2020, à la facturation électronique. Eurostat a aussi examiné l’organisation de réunions en ligne, en 2022 et 2024.
A=B donc B=A ? Pour les LLM, ça ne coule pas de source.
En 2023, nous nous étions fait l’écho d’une étude à ce sujet. Laquelle démontrait, dans les grandes lignes, que les modèles auxquels on n’avait pas appris une relation d’équivalence « dans les deux sens » (« A=B » et « B=A ») avaient du mal à la déduire.
Ce phénomène, dit reversal curse (littéralement, « malédiction de l’inversion »), figure dans une taxonomie que proposent trois universitaires américains. Ils y synthétisent l’état de la recherche sur les erreurs de raisonnement des LLM.
Leur ontologie distingue le raisonnement « incarné » (embodied, dépendant d’interactions avec des environnements physiques) et « non incarné » (qui met en jeu des processus cognitifs n’exigeant pas ces interactions). Dans le « non incarné », elle sépare raisonnement formel (qui implique la manipulation de symboles sur la base de règles) et informel (qui relève du jugement intuitif).
Les erreurs sont réparties en trois catégories :
Fondamentales (intrinsèques aux architectures et à l’entraînement des modèles)
Spécifiques à des applications
De robustesse (sensibilité à des variations mineures)
Face aux limites cognitives, imiter l’attention humaine
En matière de raisonnement informel, les erreurs peuvent découler d’un manque d’aptitudes cognitives. Les limites de la mémoire de travail en font partie (notamment le fait qu’une information ancienne peut perturber l’acquisition d’une nouvelle). Le contrôle inhibiteur aussi. Les LLM n’ont pas tous cette faculté à contenir une réaction impulsive. En tout cas au sens où peu importe l’évolution du contexte, ils s’en tiennent souvent à des patterns appris. Dans le même esprit, ils peuvent manquer de flexibilité cognitive. En d’autres termes, d’une capacité à s’adapter à de nouvelles règles et/ou à basculer efficacement entre des tâches. Le raisonnement abstrait – capacité à reconnaître des motifs dans des concepts – peut aussi leur faire défaut (déduction de règles à partir d’exemples, gestion des abstractions temporelles…).
Tous ces éléments se manifestent par des problèmes de robustesse. Ils découlent de limites d’architecture et d’entraînement : dispersion de l’attention, prédiction de tokens qui privilégie les statistiques au raisonnement, etc. S’y ajoute, pour les LLM entraînés exclusivement sur du texte, un manque d’ancrage avec le monde physique et social. Parmi les solutions explorées : insertion des chaînes de pensée dans les prompts, enrichissement de la récupération, fine-tuning avec injection d’interférences et mécanismes imitant l’attention humaine.
Des personnalités pour atténuer les biais
Au-delà du manque d’aptitudes cognitives, il y a les biais. Le contenu de l’information joue. Les LLM tendent à favoriser celle alignée sur leurs croyances ou sur le contexte précédent (reflet du biais de confirmation). Ils se révèlent également sensibles aux biais d’attribution et de négativité. Qui priorisent respectivement le contenu « populaire » et les inputs négatifs.
La présentation de l’information influe aussi. Le biais d’ordre n’épargne effectivement pas les LLM, comme le biais d’ancrage (les données présentées en premier influencent démesurément le raisonnement). S’y ajoute l’effet de cadrage (des prompts équivalents d’un point de vue logique mais formulés différemment produisent des résultats différents).La perspective narrative a également un certain poids.
Au sein de la taxonomie proposée, les erreurs relevant de biais cognitifs sont de l’ordre du fondamental. Résultant des architectures et de l’entraînement/alignement, elles se manifestent par des problèmes de robustesse. Parmi les solutions étudiées : entraînement antagoniste, filtrage des outputs et attribution de personnalités aux modèles.
La difficile acquisition des « soft skills »
Certaines erreurs de raisonnement cognitif ne se manifestent que dans des contextes sociaux spécifiques. Les LLM ne parviennent pas toujours à comprendre les normes sociales et l’état d’esprit d’autrui.
Sur ce dernier point, les difficultés tiennent autant à la compréhension des perceptions qu’à la prédiction des croyances. Le raisonnement que les modèles ont à ce propos apparaît d’autant plus fragile que des modifications mineures dans la formulation d’une tâche suffisent à le perturber. C’est sans compter les déficits sur le plan émotionnel, avec une tendance aux biais d’affect et une compréhension limitée des variations culturelles.
Sur le volet des normes sociales, il arrive que les LLM produisent des jugements contradictoires d’un point de vue éthique. Là aussi, ils se révèlent sensibles à la formulation des tâches, y compris en fonction des langues. Le fine-tuning a tendance à exacerber cette sensibilité.
Dans l’un et l’autre cas, on est sur des limites spécifiques à des applications (tâches relevant de la sûreté et de la confidentialité, en particulier). Elles se traduisent par des problèmes de robustesse – en première ligne, les risques de manipulation. Fine-tuning et apprentissage par renforcement ne constituent souvent des solutions que pour des contextes simples.
Dans les systèmes agentiques, des palliatifs durs à généraliser
Des limites, les LLM en ont aussi au niveau du raisonnement social explicite. Elles se manifestent dans les systèmes de planification agentique. Tendant à trop s’appuyer sur des informations locales ou récentes, les modèles peuvent échouer à développer des stratégies coordonnées sur le long terme.
Ces limites tiennent à la fois à leurs capacités individuelles et à la conception des systèmes agentiques. Ils se manifestent souvent par des problèmes de robustesse. Et sont accentués par les faiblesses de raisonnement social implicite comme par le manque d’aptitudes cognitives.
Parmi les solutions explorées, il y a l’enrichissement des représentations internes (suivi des croyances, validation des hypothèses). Il y a aussi des protocoles de communication avec vérification obligatoire et des agents qui « challengent » les outputs contestables. Toutes ces approches sont néanmoins difficiles à généraliser. L’ingénierie de contexte apparaît comme une méthode alternative plus robuste dans les systèmes agentiques.
Les graphes pour donner des chemins de raisonnement
En matière de raisonnement logique formel, le reversal curse est essentiellement attribué aux objectifs d’entraînement unidirectionnels des modèles transformeurs. Ils induisent en effet un asymétrie structurelle dans les poids. La principale solution explorée dans la littérature scientifique consiste à « augmenter » les données d’entraînement – entre autres par inversion syntaxique de faits et permutation d’unités sémantiques – pour restaurer une symétrie.
La raisonnement compositionnel (combinaison de connaissances) pose aussi des problèmes. On les doit aux incapacités de planification holistique et aux limites de pensée profonde. En guise de solution, outre le prompting à base de chaînes de pensée, est exploré l’entraînement à base de « chemins de raisonnement » structurés en graphes.
La syntaxe peut tout changer
L’exploitation des structures logiques implicites contenues dans les benchmarks peut révéler des problèmes de robustesse. Ce fut l’objet d’études qui ont introduit des modifications préservant la sémantique, comme changer l’ordre des réponses dans un QCM, réorganiser des prémisses ou éditer des éléments secondaires (noms de personnages, par exemple).
Ces transformations structurelles ont été appliquées aux problèmes de mathématiques comme aux benchmarks de code (édition syntaxique de docstrings, renommage de fonctions et de variables, altération de la logique de contrôle de flux…). Pour pallier les limites qu’elles ont fait ressortir, la principale solution consiste à appliquer des perturbations pour diversifier les données d’entraînement. Une technique toutefois difficile à généraliser.
Dans le domaine de l’arithmétique, les limites tiennent beaucoup à l’architecture des modèles (encodage positionnel, tokenisation…). La précision numérique limitée n’aide pas. Comme la tendance à l’usage du raisonnement heuristique (pattern matching).
Une des solutions explorées passe par des jeux de données plus précis, détaillant les étapes de traitement. Une autre imite les stratégies de calcul humaines, par exemple en focalisant l’attention sur le chiffre des unités dans le cadre des multiplications.
Le défi de l’ancrage dans le monde réel
Quantité d’analyses ont démontré le manque de bon sens des LLM sur la physique du monde réel : lois fondamentales, attributs des objets, relations spatiales… Il en résulte des erreurs fondamentales.
Même lorsqu’ils ont les compétences, les modèles échouent souvent à les appliquer à des domaines concrets. On tombe là dans les limites spécifiques à des applications.
Le fine-tuning sur des corpus qui encodent explicitement des connaissances de la physique du monde réel est une solution. L’insertion des chaînes de pensée dans les prompts en est une autre, destinée à stimuler la découverte de relations causales et spatiales plus nuancées. Piste alternative : le recours à des outils externes, tels des simulateurs.
Le manque de « bon sens physique » se reporte sur l’analyse d’images statiques, et plus encore d’environnements 3D. Les LLM ont souvent du mal à dénombrer les objets, décrire leurs relations spatiales et à détecter des anomalies. Ils ont globalement tendance à s’appuyer démesurément sur les données textuelles de leur corpus d’entraînement et sur les scénarios communs qu’ils y ont détectés. On touche là à des problèmes de robustesse, en plus de ceux spécifiques à des applications.
Les solutions étudiées incluent la modification des données d’entraînement pour réduire le biais vers le texte, les mécanismes d’attention à ancrage spatial et l’apprentissage par renforcement pour inculquer ce fameux « bon sens ».
À l’échelle des systèmes agentiques, les plans d’action comprennent parfois des actions impossibles du point de vue de la physique. On tombe là dans des erreurs fondamentales, découlant notamment d’un déficit d’affordance (raisonnement sur ce qui peut arriver à des objets).
Pas de VM à lancement fiable, de GPU sur AKS, d’actions de remédiation avec le moteur de politiques… En mode déconnecté, Azure Local a des limites fonctionnelles.
Pour autant, ce mode vient de passer en disponibilité générale. Il complète celui dit à « connectivité limitée », qui n’impose pas l’hébergement du plan de contrôle en local et qui envoie certaines données vers le cloud, à commencer par les logs.
En mode déconnecté, Azure Local permet pour le moment de créer des VM Windows (10 Enterprise ; Server 2022/2025) et Linux (Ubuntu 22.04/24.04 LTS). La gestion des clusters Kubernetes vanilla et AKS est en preview. Comme les VM à lancement fiable (secure boot, vTPM et attestation).
Le cluster de management doit comprendre au moins 3 nœuds physiques. Chacun avec 96 Go de RAM, 24 cœurs physiques et 2 To NVMe. Certaines opérations ne peuvent être effectuées sur le portail Azure, comme la création d’interfaces réseau et de clés SSH (pour AKS). On ne peut pas forcer la synchronisation des identités, réalisée toutes les 15 minutes.
Microsoft 365 adapté à Azure Local
Autre offre qui passe en disponibilité générale : Microsoft 365 Local. Elle permet de déployer Exchange Server, SharePoint Server et Skype for Business Server (Subscription Edition) sur des architectures de référence Azure Local. Impératif : utiliser du matériel certifié Premier (une vingtaine de configurations disponibles : du Dell AX et APEX, du Lenovo ThinkAgile et du HPE ProLiant).
Microsoft s’est engagé à supporter les trois produits au moins jusqu’à fin 2035.
Catalogue enrichi pour Foundry Local
Foundry Local reste en preview, mais accueille de plus gros modèles à son catalogue.
Cette version locale de Microsoft Foundry (ex-Azure AI Foundry) est installable sur Windows 10 (x64), Windows 11 (x64/Arm), Windows Server 2025 et macOS (Apple Silicon). Elle donne accès à une API et un serveur REST, un SDK (C#, Python, JavaScript) et un runtime ONNX. L’inférence est locale, mais le réseau peut être utilisé pour télécharger modèles et composants, et éventuellement partager des logs.
Pour le moment, l’API ne fonctionne qu’en mode chat/completions – le SDK permettant d’exploiter les modèles de reconnaissance vocale Whisper. Pensé pour un fonctionnement mononœud, Foundry Local ne gère ni l’autoscaling, ni la concurrence (le parallélisme est à contrôler au niveau applicatif), ni le batching continu. Quant à catalogue, avec 25 modèles, on est encore loin des plus de 8000 proposés sur la version cloud de Foundry.
Les 25 modèles disponibles
Modèle
Taille
Licence
Variantes
Phi-3-mini-4k-instruct
2,1 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (QNN, Vitis)
Phi-3-mini-128k-instruct
2,1 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (QNN, Vitis)
Phi-3.5-mini-instruct
2,1 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (QNN)
Phi-4-mini-instruct
3,6 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO)
NPU (OpenVINO, Vitis)
Phi-4-mini-reasoning
3,1 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO)
NPU (OpenVINO, Vitis)
Phi-4
8,4 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
Phi-4-reasoning
8,4 Go
MIT
CPU
GPU (CUDA, WebGPU)
DeepSeek-R1-Distill-Qwen-1.5B
1,4 Go
MIT
GPU (TensorRT)
DeepSeek-R1-Distill-Qwen-7B
5,3 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (OpenVINO, Vitis)
DeepSeek-R1-Distill-Qwen-14B
9,8 Go
MIT
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (QNN)
Qwen2.5-0.5B-Instruct
0,5 Go
Apache 2.0
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (OpenVINO, Vitis)
Qwen2.5-Coder-0.5B-Instruct
0,5 Go
Apache 2.0
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (OpenVINO, Vitis)
Qwen2.5-1.5B-Instruct
1,3 Go
Apache 2.0
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (OpenVINO, QNN)
Qwen2.5-Coder-1.5B-Instruct
1,3 Go
Apache 2.0
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (OpenVINO, Vitis)
Qwen2.5-7B-Instruct
4,7 Go
Apache 2.0
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (Vitis)
Qwen2.5-Coder-7B-Instruct
4,7 Go
Apache 2.0
CPU
GPU (CUDA, WebGPU, OpenVINO, TensorRT)
NPU (OpenVINO, Vitis)
Sans l’exprimer ainsi, IBM a tout de même fait le rapprochement, en réaction à un emballement boursier qui lui a été défavorable.
Vendredi 20 février, le titre avait clos à environ 257 $. Lundi 23, la tendance baissière constatée depuis l’ouverture s’est subitement accélérée à la mi-journée. À la fermeture, l’action avoisinait les 225 $. Son cours avait donc chuté de près de 15 %.
L’élément déclencheur fut probablement un post d’Anthropic, sur le blog consacré à ses LLM Claude. Sujet : comment l’IA « aide à passer outre la barrière du coût pour la modernisation cobol ».
Ce que dit le post d’Anthropic
Le contexte est posé d’une façon simple, pas nouvelle : de moins en moins de personnes compétentes dans ce langage, du code mal documenté qui a évolué sur des décennies… et donc d’autant plus de difficulté à moderniser. Là interviennent « des outils comme Claude Code ». Ils automatisent les phases d’exploration et d’analyse, qui « représentent l’essentiel des efforts » de modernisation.
Avec eux, « plus besoin d’une armée de consultants », ajoute Anthropic. Ils vont au-delà des graphes d’appels pour découvrir des dépendances implicites qu’une analyse statique ne révèle pas : structures de données partagées, opérations qui créent du couplage entre modules, séquences d’initialisation qui affectent l’exécution, etc.
L’IA documente aussi les workflows, identifie les risques et suggère une feuille de route, poursuit Anthropic. L’humain apporte sa connaissance des exigences réglementaires, des priorités métiers, des contraintes opérationnelles (exigences de standardisation, d’intégration…) et des degrés de tolérance auxdits risques. Il décide aussi si les tests fonctionnels suggérés suffisent, quels scénarios nécessitent une validation par des experts et quels critères de performance le code modernisé doit respecter.
La démarche est validée par étapes, sans changements massifs qui exigeraient de revenir sur des semaines de travail, conclut Anthropic.
Pourquoi IBM dénonce un amalgame
IBM ne s’en prend pas tant à ce post qu’à l’interprétation que le marché semble en avoir faite.
Traduire du code est une chose ; moderniser une plate-forme en est une autre, affirme-t-il. La valeur des mainframes réside dans leur architecture, du silicium à l’OS. De là, le défi de modernisation n’est pas un problème de conversion de langage. Le vrai travail, c’est l’ingénierie système : reconception de l’architecture data, remplacement du runtime, maintien de l’intégrité du traitement des transactions, respect des exigences non fonctionnelles embarquées.
Un simple refactoring de code ne suffit pas à répliquer des décennies d’intégration étroite entre logiciel et matériel, poursuit Big Blue. C’est là qu’il fait l’analogie avec l’iPhone.
Son propos touche aussi à un aspect qu’Anthropic n’aborde pas – tout du moins explicitement -, mais que le marché a dans son radar : comment une solution full SaaS pourrait-elle remplacer des applications mainframe ? Cela paraît difficile vu l’ampleur des dépendances on-prem, estime IBM, qui brandit de surcroît l’argument de la souveraineté et de la résidence des données.
Partant, la conversion du cobol ne serait pas un sujet de mainframes. Environ 40 % de ce code fonctionne sur Windows, Linux et d’autres systèmes distribués, avance IBM. On évitera donc l’amalgame…
Erreur humaine ou pas, toujours est-il qu’une IA, héritant des privilèges d’un ingénieur, a supprimé un environnement de production.
Une partie des commentaires sur « l’affaire Kiro » convergent en ce constat.
Amazon n’avait initialement pas communiqué à propos de l’incident, survenu mi-décembre. Il a fini par le faire la semaine dernière… après que le Financial Times l’eut révélé.
Ce qu’affirme le Financial Times
S’en référant à des employés d’Amazon, le FT déclare qu’AWS a subi, « ces derniers mois », au moins deux pannes en production dues à des erreurs impliquant ses propres outils d’IA. Il ne date pas l’une d’entre elles, qui aurait, toujours selon des employés, impliqué l’assistant Amazon Q Developer.
Celle de mi-décembre a entraîné 13 heures d’indisponibilité pour un « système utilisé par les clients ». La conséquence de modifications effectuées par l’assistant Kiro, qui avait choisi de supprimer puis de recréer un environnement.
Autre propos prêté à des employés : traités comme une « extension » des ingénieurs, les outils IA avaient les mêmes permissions. Dans l’un et l’autre cas, les personnes impliquées n’ont pas sollicité de validation des changements par un pair.
Le FT attribue certains propos directement à Amazon. D’après ce dernier, l’incident de décembre a été « extrêmement limité » : un seul service affecté, dans certaines zones de Chine continentale. Quant à l’autre incident, il n’a pas eu d’impact sur des services exposés aux clients.
Autre déclaration attribuée au groupe américain : dans les deux cas, il s’agissait d’une erreur humaine. Plus précisément un problème de contrôle d’accès : l’ingé impliqué dans l’incident de décembre avait plus de permissions qu’il n’aurait dû. Le même problème aurait pu se produire avec tout outil – doté ou non d’IA – ou toute action manuelle.
Ce que rétorque Amazon
Concernant le prétendu incident avec Amazon Q Developer, le groupe américain est catégorique : « Il est complètement faux de dire qu’un deuxième événement a impacté AWS ».
Celui de décembre a touché l’explorateur de coûts AWS (Cost Explorer), dans une de ses 39 régions cloud. Amazon juge ce périmètre « extrêmement limité » et précise n’avoir reçu aucune demande client.
L’entreprise confirme le scénario des contrôles d’accès mal configurés. C’est « une coïncidence » que des outils d’IA aient été impliqués, clame-t-elle. Et d’ajouter avoir implémenté des garde-fous « pour que cela ne se reproduise pas ». Parmi eux, une révision systématique par les pairs pour les accès en prod.
Une « directive Kiro » qui ne fait pas l’unanimité
En complément à ces éléments, un porte-parole a expliqué que l’erreur humaine n’était pas la validation de l’action par l’ingénieur, mais le fait que ce dernier n’avait pas compris quel était son niveau de privilèges. Sous-entendu : il aurait probablement agi différemment s’il avait su.
Amazon assure que par défaut, Kiro demande une validation pour chaque action qu’il souhaite effectuer. Il ne dit en revanche rien de la façon dont l’assistant a proposé de supprimer l’environnement en question. A-t-il été explicite ? Dans la négative, l’ingénieur s’est-il renseigné davantage avant de valider ?…
En toile de fond, une directive interne de novembre 2025 par laquelle Amazon pousse ses équipes à standardiser sur Kiro. Une démarche entreprise tant au nom d’une sécurité renforcée (limitation des risques de fuites de données, notamment) que d’une télémétrie unifiée.
L’initiative a suscité des remous. Plus d’un millier d’employés ont demandé de pouvoir conserver un accès à des outils, dont Claude Code. Motif : ils sont plus performants que Kiro sur des cas d’usage comme le refactoring multilangage et la gestion de certains frameworks « de niche ».
Vu les prix actuels de la RAM et des disques NVMe, comment éviter des tarifs dissuasifs sur les nouvelles gammes de serveurs ?
OVHcloud a choisi de « diluer » les coûts en les répercutant en partie sur des machines d’anciennes générations. Il a commencé à en avertir les clients concernés, avec une date à retenir : le 1er avril 2026.
À cette même échéance, les prix augmenteront chez Hetzner. Là aussi, la hausse touchera des serveurs existants. L’hébergeur allemand affirme que la démarche est devenue nécessaire autant au regard des coûts du matériel que de l’exploitation de son infrastructure (le prix de l’électricité en Allemagne reste parmi les plus élevés d’Europe). Au contraire d’OVHcloud, il a publié sa future grille tarifaire. En voici une synthèse, focalisée sur les prix horaires – l’augmentation est du même ordre pour les tarifs mensuels.
Autour de 30 % d’augmentation pour les serveurs cloud
Hetzner est présent dans deux datacenters en Allemagne (Falkenstein, en Saxe ; Nuremberg, en Bavière), un en Finlande (Helsinki), deux aux États-Unis (Ashburn, en Virginie ; Hillsboro, dans l’Oregon) et un à Singapour.
En Allemagne et en Finlande, la hausse va de 30 à 35 % pour les serveurs cloud (familles CAX, CCX, CPX et CX) et de 36 à 39 % pour les load balancers. Le stockage objet de base prend 28 % ; les extensions, 30 %.
Aux États-Unis et à Singapour, on est autour de + 30 % pour les CCX, 30 à 33 % pour les CPX et 36 à 39 % pour les load balancers.
Dans tous ces emplacements, le prix des volumes et des instantanés augmente de 30 %.
De 3 à 30 % pour les serveurs dédiés
Pour les serveurs dédiés hébergés en Allemagne :
Serveurs
AX
DX
EX
GEX
SX
Fourchette d’augmentation
3 à 31 %
16 à 17 %
12 à 15 %
16 %
5 à 17 %
Pour ceux hébergés en Finlande :
Serveurs
AX
DX
EX
SX
Fourchette d’augmentation
3 à 18 %
16 à 17 %
13 à 16 %
15 à 17 %
En Allemagne comme en Finlande, Hetzner applique une hausse de 3 % aux serveurs mis aux enchères (adjudication à la hollandaise, où le prix baisse progressivement).
Serveurs dédiés Hetzner : quelles configurations pour quels prix ?
Pour les serveurs dédiés, nous nous intéressons au prix mensuel, en euros HT, pour le moins cher et le plus cher de chaque famille. Une exception est faite pour l’EX130-R/S, actuellement introuvable dans le comparateur de prix de Hetzner.
Serveur
Config de base
Ancien prix
Nouveau prix
Différence
AX41-NVMe
Ryzen 5 3600 (Zen2, 6 cœurs, 12 threads, 3,6 GHz)
64 Go DDR4
2 x 512 Go NVMe
41,10
42,30
+ 2,9 %
AX162-R/S
Version S : EPYC 9454P (Zen4, 48 cœurs, 96 threads, 2,75 GHz)
256 Go DDR5 ECC
2 x 1,92 To NVMe Gen4Version R : même CPU, 128 Go DDR5 ECC, 2 x 3,84 To NVME Gen4
Chez OVHcloud, les anciens clients vont payer pour les nouveaux.
« Un peu injuste », admet Octave Klaba. Mais c’est « la seule solution si on veut encore avoir un Cloud accessible dans les 2 ans à venir ».
Cette forme de « solidarité » semble devoir prendre effet au 1er avril 2026. L’entreprise n’a pas fait d’annonce officielle, mais elle mentionne généralement cette date dans les e-mails envoyés aux clients concernés.
OVHcloud avait prévenu… dans une certaine mesure
Le patron d’OVHcloud avait annoncé la couleur il y a quelques semaines. Produire un même serveur coûtera 15 à 35 % fin 2026 que fin 2025, anticipait-il alors. Dans ce contexte, le prix de certains produits Cloud (gammes Public Cloud, Private Cloud et Bare Metal) « [augmenterait] de 5 à 10 % » entre avril et septembre 2026 ; et cela « [pourrait] s’accélérer ».
Deux semaines plus tard, l’intéressé avait déclaré prévoir que les prix de la RAM et des disques NVMe atteindraient un pic vers juin 2026. On venait d’apprendre que Crucial quittait le marché grand public.
Début février, il avait livré de nouvelles prédictions. Après la demande américaine en fin 2025, c’était au tour de la demande chinoise de faire monter les prix de la RAM, expliquait-il. Sa prévision : à septembre 2026, + 500 % sur un an. En y ajoutant les disques NVMe, un PC coûterait alors deux fois plus cher.
Une hausse aussi appliquée à d’anciennes générations de serveurs…
Aux dernières nouvelles, Octave Klaba ne prédit plus qu’une augmentation de 250 à 300 % entre septembre 2025 et fin 2026. Surtout, il projette, à cette même échéance, un point d’équilibre entre offre et demande. Il estime cependant que les prix resteront élevés au moins jusqu’en 2028, le temps que de nouvelles capacités de production de mémoire voient le jour.
Face à cette situation, les prix dans la gamme Cloud allaient augmenter en moyenne de 9 à 11 % sur le matériel déployé en 2026-2028, annonçait le dirigeant en date du 20 février 2026. « Pour compenser », des machines mises en service entre 2021 et 2025 seraient également facturées plus cher : + 2 à + 6 % en fonction de l’ancienneté du hardware. Dans le même temps, OVHcloud ferait « évoluer légèrement » le prix des adresses IPv4. Les nouveaux tarifs entreraient en vigueur au 1er avril ou au 1er mai 2026. Mais ne s’appliqueraient qu’à la fin des périodes d’engagement.
… au nom de l’acceptabilité des nouvelles
« J’aurais dû dire ‘quelques euros ou 9/11%’ », a fini par reconnaître Octave Klaba en réponse à un client français s’étonnant de « [se] prendre plus de 50 % d’augmentation » pour un VPS souscrit fin 2025.
Il n’y a pas qu’en France que les prix des VPS flambent. Au Canada, par exemple, des témoignages font état de hausses dépassant les 50 %, voire se rapprochant des 100 %. Sur place, les IPv4 supplémentaires ont effectivement aussi augmenté, passant à 2,39 $ HT.
Hormis les VPS, l’augmentation touche les serveurs dédiés Advance 2024 et 2026, ainsi que Rise-S, M, L et XL. Pas les Kimsufi, les So you Start, ni les Rise-1, 2, 3 et 4.
Octave Klaba ne le cache pas : diluer ainsi les coûts sur plusieurs gammes, y compris de produits non orientés RAM, est censé « éviter que les clients trouvent le Cloud 2026-2028 trop cher ». Reste que plus d’un a du mal à digérer l’idée de subir une augmentation sur des serveurs dont les composants ont été acquis avant la flambée des prix et qui ont déjà été amortis.
Il y a 3 ans, c’était l’énergie
OVHcloud n’a pour le moment rien officialisé et n’a pas modifié ses tarifications publiques. Peut-être se laisse-t-il le temps de prendre la température.
La dernière hausse de prix d’une ampleur comparable dans la gamme Cloud était intervenue fin 2022. Elle fut imputée essentiellement au coût de l’énergie, d’autant plus qu’une partie des couvertures d’achat d’OVHcloud arrivaient à terme.
Au catalogue VPS, les serveurs Elite avaient pris 16 % ; les Value, 17 % ; les Comfort, 19 % ; les Starter, 20 % ; les Essential, 28 %.
Dans la famille Bare Metal, OVHcloud avait appliqué une hausse d’environ 10 % pour les serveurs Advance (sauf ADV-1), Scale (sauf Scale-7) et High Grade. En Bare Metal Eco, ce fut + 10 à + 12 % pour les Kimsufi (sauf KS-1), 10 à 11 % pour les So you Start et 10 % pour les Rise.
Sur la partie Public Cloud, les hausses allèrent de 4 à 10 % pour les serveurs à usage général comme pour ceux orientés RAM ; de 5 à 10 % pour ceux orientés CPU et de 9 à 10 % pour ceux orientés GPU.
Le stockage bloc avait pris 7 % ; le stockage objet, 10 % ; les snapshots et les backups, 13 %.
Quelques semaines plus tôt, les IPV4 supplémentaires étaient passées sur un modèle d’abonnement mensuel. Précédemment, il n’en coûtait que des frais de mise en service.
En matière de décisions marketing malheureuses, il y eut le New Coke et il y aura bientôt Everpure.
Entre autres commentaires dubitatifs, le rebranding de Pure Storage en a inspiré un de cette teneur.
L’entreprise américaine n’a pas seulement changé de marque commerciale. Depuis le 23 février 2026, Everpure est sa nouvelle dénomination sociale. Un choix censé refléter l’évolution de son positionnement, de la gestion du stockage à la gestion des données.
Le nouveau nom de domaine (everpuredata.com) redirige pour le moment vers l’ancien (purestorage.com). Ils vont coexister ces prochains mois, la transition se faisant « par phases ». Le rebranding s’appliquera aussi, entre autres, aux communautés, à la documentation, aux réseau sociaux… et aux badges de certification. En Bourse, Pure Storage deviendra Everpure le 5 mars 2026, mais conservera le symbole PSTG.
Catégorie
Ancien nom
Nouveau nom
Société
Pure Storage
Everpure
Produits
Plateforme Pure Storage
Plateforme Everpure
FlashArray, FlashBlade
Pas de changement
Famille Pure//E
Famille Everpure//E
Evergreen//One, Flex, Forever et Foundation
Pas de changement
Pure Storage Cloud
Everpure Cloud
Pure Protect
Everpure Protect Service
Portworx by Pure Storage
Portworx by Everpure
Data Stream
Everpure Data Stream Services
Architecture
Evergreen
Pas de changement
Capacités-clés
Purity
Pas de changement
Fusion
Pas de changement
Pure1
Pas de changement
Autres sous-marques
(Safemode, Active Cluster, etc.)
De manière générale, pas de changement ; utiliser la marque Everpure à la place de Pure Storage lorsque c’est applicable.
1touch, une première acquisition sous l’ère Everpure
Pure Storage / Everpure accompagne son discours data management d’un concept architectural : l’EDC (Enterprise Data Cloud). Introduit à l’été 2025, il unifie stockage bloc, fichier et objet* en une data fabric pilotée par logiciel. La plate-forme Everpure en constitue l’incarnation, avec des composantes telles que Fusion (orchestration), Pure1 (AIOps) et Portworx (gestion des conteneurs).
Pour renforcer l’ensemble, un projet d’acquisition vient d’être annoncé – avec l’intention de le boucler d’ici à la fin du deuxième trimestre de l’exercice fiscal en cours, soit début août 2026. La cible : 1touch, qui a justement développé une plate-forme de data management. Anciennement appelé Inventa, le produit a pris le virage de l’IA et est devenu Kontxtual.
* Dans le dernier Magic Quadrant des « plates-formes de stockage d’entreprise », Pure Storage fait partie des « leaders » avec Dell, HPE, Huawei, IBM et NetApp. Gartner salue la qualité du support, la gestion de flotte… et la gestion bloc-fichier-objet unifiée en un pool virtualisé.
Connexion
