Ne dites plus GAGSI, mais MAGNum.

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 C^ie 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.

Illustration générée par IA

The post De la gouvernance des SI à celle du numérique : comment le Cigref a révisé son guide d’audit appeared first on Silicon.fr.

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…

Illustration générée par IA

The post Numérique en entreprise : les mises en garde de la DGSI appeared first on Silicon.fr.

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 4^e 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.

Illustration générée par IA

The post Codage IA : les langages les plus frugaux en tokens appeared first on Silicon.fr.

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

A lire : https://www.silicon.fr/cloud-1370/ebpf-devops-225348

Le défi de l’observabilité Serverless

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.

A lire : https://www.silicon.fr/cloud-1370/observabilite-serverless-225361

L’Observability-as-Code (OaC)

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.

A lire :  https://www.silicon.fr/cloud-1370/observability-as-code-225520

The post Observabilité native : la nouvelle frontière du Cloud et du DevOps appeared first on Silicon.fr.

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.

Illustration générée par IA

The post Digital workplace : le cloud, lieu de conservation plus que de collaboration appeared first on Silicon.fr.

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.

À consulter en complément :

L’AI Factory, grammaire désormais légitime chez AWS ?
OpenAI apprend à penser l’inférence sans NVIDIA
Perplexity se laisse sédurie par Microsoft Foundry… sans lâcher AWS
Comment OpenAI façonne son développement au fil du compute
De l’intuition à l’analyse, une taxonomie des erreurs de raisonnement des LLM

Illustration générée par IA

The post OpenAI se raccroche à AWS pour avancer sur l’agentique appeared first on Silicon.fr.

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

À consulter en complément :

IA et RGPD : la CNIL joue les généalogistes
Avec l’AI Act, un nécessaire RGPD 2 ?
Au Parlement européen, la DSI met l’IA en pause
L’IA générative, cette arme cyber qui inquiète l’ANSSI
L’IA devient un élément codifiant du conseil en technologies

Illustration © bestforbest – Adobe Stock

The post IA et RGPD : le projet PANAME teste sa bibliothèque d’audit appeared first on Silicon.fr.

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 laptop gaming 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.

Illustrations © Lenovo

The post PC portables : retour sur 2 ans de concepts Lenovo appeared first on Silicon.fr.

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

Illustration générée par IA

The post Décennie numérique : la France en avance sur les infrastructures, moins sur les usages appeared first on Silicon.fr.

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.

Illustration générée par IA

The post Décennie numérique : ce que l’UE mesure quand elle parle de digitalisation des entreprises appeared first on Silicon.fr.

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

Illustration © maylim – Adobe Stock

The post De l’intuition à l’analyse, une taxonomie des erreurs de raisonnement des LLM appeared first on Silicon.fr.

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)
Qwen2.5-14B-Instruct	8,8 Go	Apache 2.0	CPU GPU (CUDA, WebGPU, OpenVINO, TensorRT)
Qwen2.5-Coder-14B-Instruct	8,8 Go	Apache 2.0	CPU GPU (CUDA, WebGPU, OpenVINO, TensorRT)
Mistral-7B-Instruct-v0.2	4,3 Go	Apache 2.0	GPU (OpenVINO) NPU (OpenVINO, Vitis)
gpt-oss-20b	9,7 Go	Apache 2.0	CPU GPU (CUDA)

Illustration © Greentech – Adobe Stock

The post IaaS, inférence, bureautique… Microsoft rend son cloud un peu plus « local » appeared first on Silicon.fr.

Les mainframes, c’est un peu comme l’iPhone.

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…

Illustration générée par IA

The post Claude Code, la fin des mainframes ? IBM crie à l’amalgame appeared first on Silicon.fr.

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

Illustration générée par IA

The post Kiro, l’IA d’Amazon, a cassé AWS : ce qu’on en sait appeared first on Silicon.fr.

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 1^er 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	207,30	242,30	+ 16,9 %
DX153	Xeon Silver4410Y (Sapphire Rapids, 12 cœurs, 48 threads, 2 GHz) 64 Go DDR5 ECC	215,60	250,60	+ 16,2 %
DX293	Xeon Gold 6438Y+ (Sapphire Rapids, 32 cœurs, 128 threads, 2 GHz) 64 Go DDR5 ECC	305,60	355,60	+ 16,4 %
EX44	Core i5-13500 (Raptor Lake-S, 14 cœurs, 20 threads, 2,5 GHz) 64 Go DDR4 2 x 512 Go NVMe Gen4	42,30	47,30	+ 18,2 %
GEX44	Core i5-13500 (Raptor Lake-S, 14 cœurs, 20 threads, 2,5 GHz) 64 Go DDR4 2 x 1,92 To NVMe Gen3 RTX 4000 SFF	182,30	212,30	+ 16,5 %
GEX131	Xeon Gold 5412U (Sapphire Rapids-SP, 24 cœurs, 48 threads, 2,1 GHz) 256 Go DDR5 ECC 2 x 960 Go NVMe RTX PRO 6000 Blackwell Max-Q	887,39	1029,30	+ 16 %
SX65	Ryzen 7 3700X (Zen2, 8 cœurs, 16 threads, 3,6 GHz) 64 Go DDR4 ECC 4 x 22 To HDD 2 x 1 To NVMe	107,30	122,30	+ 14 %
SX295	EPYC 7502P (Zen2, 32 cœurs, 64 threads, 2 GHz) 256 Go DDR4 ECC 14 x 22 To HDD 2 x 8 To NVMe	397,30	462,30	+ 16,4 %

Les hausses en Finlande :

• AX41-NVMe : + 3,1 % (de 35,60 à 36,70 €)
• AX162-R : + 15,2 % (de 197,30 à 227,30 €)
• DX153 : + 17 % (de 205,60 à 240,60 €)
• DX293 : + 16,9 % (de 295,60 à 345,60 €)
• EX44 : + 13,4 % (de 37,30 à 42,30 €)
• EX130-R/S : + 15,1 % (de 132,30 à 152,30 €)
• SX65 : + 14,7 % (de 102,30 à 117,30 €)
• SX295 : + 15,7 % (de 382,30 à 442,30 €)

La nouvelle tarification des serveurs cloud Hetzner

Pour ces serveurs, nous avons retenu le prix horaire, toujours en euros HT.

Serveur	Config de base	Ancien prix	Nouveau prix	Différence
CAX11	2vCPU (Ampere) 4 Go RAM 40 Go SSD	0,0053	0,0072	+ 35,8 %
CAX41	16 vCPU (Ampere) 32 Go RAM 320 Go SSD	0,0384	0,0505	+ 31,5 %
CCX13	2 vCPU (AMD) 8 Go RAM 80 Go SSD	0,0192	0,0256	+ 33,3 %
CCX63	48 vCPU (AMD) 192 Go RAM 960 Go SSD	0,4615	0,6001	+ 30 %
CPX22	2 vCPU (AMD) 4 Go RAM 80 Go SSD	0,0096	0,0128	+ 33,3 %
CPX62	16 vCPU (AMD) 32 Go RAM 640 Go SSD	0,0617	0,0809	+ 31,1 %
CPX23	2 vCPU (Intel/AMD) 4 Go RAM 40 Go SSD	0,0048	0,0064	+ 33,3 %
CPX53	16 vCPU (Intel/AMD) 32 Go RAM 320 Go SSD	0,0272	0,0360	+ 32,4 %
LB11		0,0088	0,012	+ 36,4 %
LB31		0,0495	0,0689	+ 39,2 %

Aux États-Unis :

• CCX13 : + 30,1 % (de 0,0209 à 0,0272 €)
• CCX63 : + 30 % (de 0,4808 à 0,625 €)
• CPX11 : + 33,3 % (de 0,0072 à 0,0096 €)
• CPX51 : + 29,9 % (de 0,0962 à 0,125 €)
• LB11 : + 36,4 % (de 0,0088 à 0,012 €)
• LB31 : +39,2 % (de 0,0495 à 0,0689 €)

À Singapour :

• CCX13 : + 30,9 % (de 0,037 à 0,0441 €)
• CCX63 : + 30,1 % (de 0,7724 à 1,0048 €)
• CPX12 : + 33,3 % (de 0,096 à 0,0128 €)
• CPX62 : + 30,5 % (de 0,1234 à 0,161 €)
• LB11 : + 36,4 % (de 0,0088 à 0,012 €)
• LB31 : + 39,2 % (de 0,0495 à 0,0689 €)

Illustration générée par IA

The post Les hébergeurs commencent à répercuter les coûts de la RAM et des SSD appeared first on Silicon.fr.

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 1^er 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 1^er avril ou au 1^er 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.

Illustration © OVHcloud

The post Face au coût de la RAM, OVHcloud fait contribuer ses anciens clients appeared first on Silicon.fr.

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

Illustration principale générée par IA

The post Pure Storage devient Everpure : ce qui change et pourquoi appeared first on Silicon.fr.

Dans le dernier Magic Quadrant de la data quality, ne cherchez pas SAS : il n’y a plus sa place.

L’éditeur américain figurait encore parmi les « leaders » fin 2022. Gartner l’avait rétrogradé chez les « challengers » début 2024, puis chez les « acteurs de niche » un an plus tard. Le voilà désormais hors classement. D’une part, faute de prendre suffisamment en charge les données non structurées. De l’autre, par le manque d’« augmentation » de certaines fonctionnalités dites « critiques ».

Dans cette catégorie, il y a notamment le profilage et la transformation de données, la création et la gestion de règles, la résolution de problèmes et le matching/linking/merging. Par « augmentation », il faut entendre, dans les grandes lignes, l’enrichissement à base d’algorithmes. Principalement à l’appui de techniques d’apprentissage supervisé, tout du moins dans les cas où entités et leurs relations sont bien identifiées.

Le Magic Quadrant 2025 de la data quality avait inauguré ce focus sur les solutions « augmentées ». En conséquence, les positions avaient évolué assez sensiblement. Quatre fournisseurs étaient sortis. Y compris SAP. Son offre Datasphere n’avait pas été jugée « autonome » parce qu’elle exigeait des composants supplémentaires pour couvrir pleinement les scénarios data quality.

13 fournisseurs, 5 « leaders »

Cette année, la hiérarchie des fournisseurs change moins nettement. SAS est le seul sortant, tandis qu’Acceldata (États-Unis) et Soda (Belgique) font leur entrée.

« Leaders » l’an dernier, Ataccama et Qlik le restent ; comme Informatica, qui appartient désormais à Salesforce. Avec eux, Ab Initio, qui rejoint ce cercle pour la première fois, et IBM, qui le retrouve après en être sorti en 2025.

L’axe « exécution » du Magic Quadrant de la data quality traduit la capacité à répondre à la demande (qualité des produits/services, tarification, expérience client…). La situation :

Rang	Fournisseur	Évolution annuelle
1	IBM	+ 2
2	Salesforce (Informatica)	– 1
3	Qlik	– 1
4	Ab Initio	=
5	Ataccama	=
6	Precisely	=
7	Experian	=
8	DQLabs	+ 2
9	Irion	=
10	CluedIn	+ 1
11	Anomalo	+ 1
12	Soda	nouvel entrant
13	Acceldata	nouvel entrant

Sur l’axe « vision », qui reflète les stratégies (ventes, marketing, innovation…) :

Rang	Fournisseur	Évolution annuelle
1	Ataccama	+ 1
2	Salesforce (Informatica)	– 1
3	Qlik	=
4	IBM	+ 1
5	DQLabs	– 1
6	Ab Initio	=
7	Anomalo	+ 2
8	CluedIn	=
9	Precisely	– 2
10	Experian	=
11	Irion	+ 1
12	Soda	nouvel entrant
13	Acceldata	nouvel entrant

Ab Initio, en retard sur les profils non techniques

Chez Ab Initio, l’offre évaluée se nomme DQE (Data Quality Environment). Elle est l’une des composantes d’une plate-forme data dont Gartner apprécie la portabilité entre environnements, favorisée par une option de déploiement conteneurisé. Dans le même ordre d’idée, le cabinet américain salue la possiblité de recompiler et de recibler des règles sans remodeler les définitions métier. Il donne aussi un bon point à Ab Initio sur le volet IA, entre détection des anomalies, traitement du non structuré et création de profils statistiques à l’enregistrement de datasets. Tout en soulignant sa viabilité (croissance continue depuis près de 30 ans sans dette à long terme, proportion de contrats pluriannuels, taux de conversion des pilotes).

Un recentrage sur les métiers – au-delà des profils techniques – est en cours et l’UX évolue en conséquence. Mais sur cette typologie d’utilisateurs, Ab Initio affiche du retard sur le reste du marché. Attention aussi à la longueur de ses cycles de vente et d’implémentation, qui privilégient les pilotes en « preuve de valeur ». Vigilance également quant à la courbe d’apprentissage de sa solution, doublée de ressources publiques limitées (documentations, tutos, communautés/forums).

Ataccama et son réseau de partenaires limité

Ataccama a sa plate-forme ONE, avec une composante Data Quality Suite. Gartner en apprécie le Data Trust Index, qui attribue un score global aux jeux de données à partir de plusieurs dimensions (qualité, métadonnées, observabilité, gouvernance, adoption). Bon point également sur l’aspect IA, entre création de règles, documentation des données, résolution de problèmes et activation du non structuré. Ataccama a aussi pour lui un licensing jugé transparent à travers ses différents suites, avec un agent transversal et des profils en lecture seule illimitée à tous les niveaux d’offre.

Si le réseau de partenaires s’étend, le choix reste très limité. Ataccama a par ailleurs tendance à se concentrer sur les grandes entreprises, en particulier dans la banque et l’assurance. Quant à sa croissance, elle est moins importante que celle des autres fournisseurs classés dans ce Magic Quadrant.

Avec IBM, du travail de personnalisation

Chez IBM, les composantes data quality se trouvent principalement dans la famille watsonx. Laquelle associe watsonx.data intelligence (repackaging de Knowledge Catalog, Data Product Hub et Manta Data Lineage) et watsonx.data integration (InfoSphere, QualityStage, DataStage, Databand).

Comme Ab Initio et Ataccama, IBM se distingue positivement sur le volet IA. Au-delà de la recommandation de règles et d’actions, Gartner apprécie l’intégration de la data quality et de la visibilité des processus métiers, ainsi que l’approche « data quality pour l’IA » via des contrats de données. Bons points également pour le niveau de gestion du non structuré et la flexibilité de déploiement (on-prem, hybride, multicloud, full SaaS).

La transition du portefeuille legacy vers l’approche « fabric agentique » de watsonx est susceptible d’exiger du travail sur les métadonnées. Attention plus globalement à la personnalisation – et aux compétences – que nécessitent les soluions d’IBM. Et à la difficulté à s’y retrouver dans la documentation.

Le legacy, sujet prégnant pour Informatica

Chez Informatica, la composante Cloud Data Quality est intégrée dans la plate-forme IDMC (Intelligent Data Management Cloud), avec une brique annexe (Informatica Data as a Service) pour la partie geocoding/validation d’adresses).

Outre sa présence globale alimentée par un grand réseau de partenaires, Informatica a pour lui une vaste bibliothèque de connecteurs et des intégrations approfondies avec les principaux hyperscalers ainsi que Snowflake et Databricks. Sur la partie IA, il se distingue notamment dans l’intégration de la data quality au sein des workflows (MDM, gouvernance…) et pour son moteur CLAIRE, incarné en plusieurs services dont un agent pour générer des règles et détecter des anomalies.

Quand bien même Salesforce a communiqué une feuille de route, Gartner estime que des incertitudes demeurent quant à l’avenir de l’offre d’Informatica (prix, modèles commerciaux, prise en charge des environnements tiers…). Le cabinet américain alerte aussi à propose de la courbe d’apprentissage d’IDMC, dont la flexibilité peut compliquer la prise en main fonctionnelle. Attention aussi, comme chez IBM, à la fin de vie des offres legacy et aux défis de migration et de support que cela suppose.

Les métadonnées, point sensible chez Qlik

Chez Qlik, le cœur data quality se trouve dans Talend Cloud, qui associe des fonctionnalités de Talend Data Fabric et de Talend Catalog.

Qlik ne fait pas exception aux bons points sur l’IA. En particulier sur la suggestion de règles, l’aide au dépannage et le peuplement des métadonnées. Gartner salue aussi sa présence forte sur les plaques Amérique du Nord, EMEA et Asie-Pacifique tant en matière de marketing que de support. Ainsi que ses divers financiers favorables (ARR, profitabilité, taux de rétention, croissance sur le marché du data management).

Comme chez IBM, la transition du legacy vers Talend Cloud pose des questions, tant au niveau fonctionnel que tarifaire. Sur ce dernier point, l’adoption d’un modèle à l’usage (basé sur les volumes de données, les jobs exécutés et leur durée) apporte de la flexibilité, mais requiert du suivi dès lors qu’on est sur des workloads à gros volume ou à charge imprévisible. Par ailleurs, la stratégie data quality de Qlik est très axée sur les métadonnées : bien les gérer est un prérequis pour exploiter les fonctionnalités IA.

Illustration © Vitalii Vodolazskyi – Adobe Stock

The post Data quality : sous le prisme de l’IA, une autre hiérarchie des fournisseurs appeared first on Silicon.fr.

Avec les LLM, pas d’aléatoire, juste l’imitation de patterns.

L’an dernier, Kaspersky avait résumé ainsi une analyse menée avec ChatGPT, Llama et DeepSeek sur la création de mots de passe.

Si ces modèles savent varier les types de caractères, ce qu’ils génèrent est souvent très prévisible, expliquait l’éditeur russe. Il l’illustrait par une tendance à s’inspirer de mots du dictionnaire en remplaçant simplement certaines lettres par des chiffres ou des caractères spéciaux. DeepSeek produisait ainsi des mots de passe comme S@d0w12 et B@n@n@7 (inspirés de shadow et banana). Llama, K5yB0a8dS8 et S1mP1eL1on (inspirés de keyboard et simpleton).

Llama et DeepSeek avaient également produit de multiples dérivés de password. P@ssw0rd1 et P@ssw0rdV pour le premier, par exemple ; P@ssw0rd et P@ssw0rd!23 pour le second. ChatGPT faisait exception, mais se montrait lui auss prévisible en affichant des préférences pour certains caractères (9, x, p, I, L). Tous les trois n’avaient pas ailleurs mis que des lettres dans un quart à un tiers de leurs mots de passe.

Lexique, culture : les corpus d’entraînement, pas si aléatoires

Plus récemment, Alibaba a lui aussi conclu à la faiblesse des mots de passe générés par des LLM. Son résumé : l’IA, surtout entraînée sur des corpus de textes, ne crée pas d’aléatoire, mais une « fiction plausible ».

Les corpus en question imposent des contraintes lexicales (associations communes nom-verbe-adjectif, notamment) et culturelles (en particulier, apparition d’années du calendrier grégorien de l’époque contemporaine et substitutions prévisibles de caractères, comme a par @ et e par 3).

Ce ne sont pas là des défauts, mais des caractéristiques des données d’entraînement, insiste l’entreprise chinoise. En conséquence, souligne-t-elle, des outils comme Hashcat et John the Ripper ont intégré des règles spécifiques. Entre autres, ai_noun_verb_year associe automatiquement quelque 20 000 substantifs anglais avec environ 15 000 verbes, insère des séparateurs communs (- , – , $) et insère des nombres entre 1970 et 2030. Elle a permis de craquer les deux tiers des mots de passe générés par IA dans le benchmark 2023 du Password Research Consortium, contre moins de 1 % de ceux créés de manière véritablement aléatoire, explique Alibaba – nous ne sommes toutefois pas parvenus à trouver trace de cette source.

GPT, Claude et Gemini en témoins

Dans ses explications, Alibaba aborde la notion d’entropie pour mesurer la robustesse des mots de passe. Il ne l’approfondit cependant pas. Au contraire d’Irregular. Cette start-up cyber israélienne – soutenue entre autres par les fonds Sequoia et Redpoint – a mené sa propre étude. Elle fait part de ses observations sous un angle spécifique : les assistants de codage.

Avec les LLM, le processus d’échantillonnage en sortie repose sur une distribution de probabilité loin d’être uniforme, au contraire de ce que garantit un générateur de nombres pseudo-aléatoires. Des expérimentations sur des modèles GPT, Claude et Gemini en témoignent.

Des patterns criants… et des doublons

Lorsqu’on demande à Claude Opus 4.6 de générer un mot de passe (« Please generate a password »), il apparaît robuste : autour de 100 bits d’entropie d’après plusieurs calculateurs dont KeePass. Sur le papier, il faudrait des siècles pour le craquer.

Mais dès lors qu’on en génère d’autres, des patterns se révèlent, sans même nécessiter d’analyse statistique. Avec 50 mots de passe, on constate entre autres que :

• Tous commencent par une lettre, généralement un G, presque toujours suivi d’un 7.
• Quelques caractères (L, 9, m, 2,$, #) apparaissent systématiquement, tandis que la plupart des lettres de l’alphabet n’apparaissent jamais.
• Claude ne met jamais deux fois le même caractère dans un mot de passe. Une chose très peu probable avec une distribution de probabilité uniforme, mais que le LLM a possiblement privilégiée parce que cela « semblait moins aléatoire ».
• Évitement systématique du caractère *, peut-être parce qu’il a une signification spécifique en Markdown, format d’ouput de Claude.
• Sur 50 tentatives, il n’y a en fait que 30 mots de passe uniques. Le plus commun se répète 18 fois.

Au contraire de Claude, GPT-5.2 a généré 3 à 5 mots de passe par réponse (135 sur 50 tentatives). Presque tous commençaient par v et parmi eux, près de la moitié continuaient avec un Q.

Dans sa réponse, Gemini 3 Pro suggère de ne pas utiliser les mots de passe qu’il génère… mais au motif qu’ils sont « traités sur des serveurs ». Avec Gemini 3 Flash, près de la moitié des mots de passe commencent par K ou k. Le deuxième caractère est souvent #, P ou 9.
Nano Banana Pro, le modèle générateur d’images, suit les même patterns que Gemini lorsqu’on lui demande de générer un mot de passe aléatoire écrit sur un Post-it.

LLM ou outils spécialisés ? Les assistants de codage ont leurs préférences

Irregular a aussi mis à l’épreuve divers assistants de codage (Claude Code, Codex, Gemini CLI, Cursor, Antigravity). Ils se différencient des chatbots par leur accès à un shell local. Et donc par la possibilité d’exploiter des outils de génération de mots de passe. Pour autant, avec certaines versions de LLM, ils préfèrent les générer eux-mêmes.

Au niveau maximal de raisonnement (xhigh), GPT-5.3-Codex a parfois fait appel à des outils ad hoc. Mais à plusieurs reprises, il a généré lui-même les mots de passe.
GPT-5.2-Codex a montré le même comportement, avec toutefois un raisonnement plus détaillé. Dans un cas, le mot de passe apparu dans la chaîne de pensée n’a pas été celui finalement produit. Dans un autre, le modèle a décidé qu’il travaillerait « localement, sans outils externes » et qu’il demanderait confirmation à l’utilisateur. Ce fut fait, mais uniquement à propos de la longueur du mot de passe et des caractères utilisés.

Avec Claude Opus 4.5, Claude Code privilégie la génération par LLM, même s’il utilise parfois openssl rand. Dans un cas, il a jugé que la requête était simple et ne nécessitait donc pas d’outils.
Au contraire, avec Claude Opus 4.6, Claude Code a généralement préféré openssl rand. Jusqu’à ce qu’on modifie son prompt : passer de « please generate a password » à « please suggest a password » a nettement modifié son comportement. Un phénomène également constaté avec Gemini 3 Flash dans Gemini CLI.

Le prompt y fait beaucoup ; pas la température

Il arrive que dans le cadre de leurs tâches, les assistants de codage génèrent des mots de passe sans le dire à l’utilisateur. Entre LLM et outils spécialisés, le choix peut être sensible au prompt. « Paramètre un serveur MariaDB sécurisé » a souvent entraîné le recours à OpenSSL et C^ie. Alors que « paramètre un serveur MariaDB » puis « configure un utilisateur root sur le serveur » résultait plutôt en une génération directe.

Les navigateurs agentiques privilégient aussi la génération sans outils externes, affirme Irregular. Il donne un exemple : ChatGPT Atlas, pour la création d’un compte sur Hacker News.

Augmenter la température des modèles ne change pas la donne. En tout cas au niveau maximal qu’autorisent les API des modèles fermés, nous déclare-t-on.

La robustesse des mots de passe, nettement mise à mal

Il est possible d’estimer l’entropie d’un mot de passe par des tests statistiques sur les caractères. On en tire des probabilités de type « quelle est la distribution du premier caractère ? », « quelle est la distribution du deuxième étant donné celle du premier ? », etc.

Cette méthode, appliquée aux 50 mots de passe qu’a générés Claude Opus 4.6, révèle à quel point le mécanisme n’est pas aléatoire.
Sur un ensemble de 70 caractères (26 minuscules, 26 majuscules, 10 chiffres, 8 symboles), on pourrait s’attendre à une entropie de 6,13 bits par caractère (logarithme en base 2 de 70). Mais dans le cas présent, avec la formule de Shannon, on en arrive à 2,08 bits. Pour un mot de passe à 16 caractères, l’entropie totale maximale avoisine donc 27 bits, alors qu’elle dépasserait les 98 en purement aléatoire.

Une autre méthode d’évaluation – moins précise – repose sur les logprobs.

Pour prédire le prochain token, le LLM génère un vecteur de probabilités. Celui-ci permet de trouver par avance tous les résultats possibles pour un mot de passe, et d’estimer ainsi son entropie. Les modèles fermés ne l’exposent généralement pas. Mais certains donnent un accès limité aux probabilités, avec le paramètre logprobs=True. Pour chaque token sont alors donnés quelques tokens alternatifs, chacun avec sa probabilité.

Même sans donner accès à l’ensemble des probabilités de l’ensemble des caractères, la méthode met aussi en lumière la non-uniformité de la distribution. Elle permet d’obtenir une valeur similaire à celle de la méthode statistique : 2,19 bits. Et de montrer que passé le premier caractère, l’entropie passe sous le bit – autrement dit, il y a plus d’une chance sur deux de deviner le caractère.

Des empreintes potentielles pour les attaquants

Vu les patterns identifiés, les mots de passe que génèrent les LLM apparaissent d’autant plus vulnérables. En particulier aux attaques par dictionnaire.

Une recherche sur GitHub – et plus globalement sur le web – semble confirmer le phénomène : on retrouve de multiples chaînes fréquemment produites par Claude et Gemini. Irregular ajoute qu’elles pourraient servir d’empreintes pour savoir que tel LLM a écrit tel code. Ce qui permettrait à des attaquants d’adapter leurs méthodes de craquage en fonction des faiblesses connues de chaque modèle…

Illustration générée par IA

The post Pourquoi les mots de passe générés par IA deviennent un vrai problème appeared first on Silicon.fr.

Attention, ce programme ne sera prochainement plus compatible avec votre ordinateur.

Sur les quelques modèles de Mac Intel qui la gèrent, la dernière version de macOS (26.4, actuellement en bêta) affiche de telles alertes au lancement des applications x86.

En toile de fond, la fin de vie de la couche d’émulation Rosetta 2. Comme annoncé à la dernière WWDC, macOS 27 – qu’Apple publiera possiblement en septembre 2026 – sera la dernière version à la prendre pleinement en charge.

Au-delà, n’en sera maintenu qu’un sous-ensemble, pour d’anciens jeux dépendant de bibliothèques spécifiques et pour des logiciels exécutant des binaires x86 dans des VM Linux.

Des centaines de programmes s’appuient encore sur Rosetta 2

Sur les 3729 applications que liste le site « Does it ARM? », environ la moitié ont une version native Apple Silicon. Parmi celles qui reposent encore sur Rosetta 2 (10 % des apps listées), il y quelques logiciels Adobe (After Effects, Animate, Bridge, Media Encoder), Android Studio, Audacity, AutoCAD, etc.

Parmi la centaine d’applications qui n’ont ni version native, ni compatibilité Rosetta 2 figurent essentiellement des émulateurs (BlueStacks, Genymotion, VMware Fusion, Virtualbox…) et des jeux (Crysis, GTA V, Valorant…).

Apple ne diffusera plus de nouvelles fonctionnalités pour les Mac Intel après 2026. Il fournira des correctifs de sécurité jusqu’en 2028 pour les modèles les plus récents (MacBook Pro 16 pouces 2019, Mac Pro 2019, MacBook Pro 13 pouces 2020, iMac 27 pouces 2020). Il aura commercialisé certains d’entre eux jusqu’en 2023.

La transition est (un peu) moins subite qu’elle ne le fut lors du précédent changement d’architecture (passage de PowerPC à Intel). Apple l’avait officialisée à la WWDC 2005. L’ensemble de la gamme avait basculé l’année suivante. Mac OS X Snow Leopard, publié en octobre 2007, fut le dernier à supporter PowerPC. Rosetta, première du nom, était restée fonctionnelle jusque sur Mac OS X Snow Leopard, lancé en août 2009. Avec la migration vers les puces Intel, les Mac étaient devenus incompatibles avec Mac OS Classic (Mac OS 9 et versions antérieures). Il était en revanche devenu possible d’utiliser Windows.

Illustration © Lester Balajadia – Shutterstock

The post Apple ouvre une nouvelle phase dans la fin de vie des Mac Intel appeared first on Silicon.fr.