Depuis son ouverture en 2010, l'autoroute A65 reliant Langon à Pau n'a jamais atteint ses objectifs de trafic : seulement 7 500 véhicules quotidiens contre 10 000 à 14 000 prévus. Cet investissement massif de 1,2 milliard d'euros était déjà remis en question par un audit d'État en 2003, bien avant sa construction.La fintech britannique Revolut affirme avoir réduit d'environ 90 % sa facture d'IA de codage en moins d'un an, en remplaçant les outils commerciaux comme Claude Code, l'assistant de programmation d'Anthropic, par un modèle chinois hébergé sur ses propres serveurs.
David Abitbol, qui dirige l'infrastructure de la banque en ligne, a raconté la bascule lors d'une conférence à New York. Ses 2 000 ingénieurs sont passés de Gemini début 2025 à Claude Code début 2026, avant d'adopter GLM, un modèle ouvert développé par le chinois Z.ai et utilisé aujourd'hui en version 5.3.
Le calcul est vite fait. Auto-hébergé, GLM revient à 0,30 dollar le million de tokens, ces unités de texte que les fournisseurs d'IA facturent à la consommation, soit à peu près dix fois moins que Claude Code ou que Codex, son équivalent chez OpenAI. Certains développeurs coûtaient jusqu'à 10 000 dollars par mois, pour un retour jugé décevant en interne.
Le tout tourne sur 56 cartes graphiques Nvidia B200 installées chez Revolut. Plutôt que d'empiler les cartes, les équipes ont surtout gratté de la performance avec des réglages fins, comme la compression du modèle ou la séparation des différentes phases de calcul.
Côté performances, la première réponse tombe en moins de 3 secondes et le système sort environ 200 tokens par seconde, et même 800 le soir quand les bureaux se vident. Au-delà de 5 secondes d'attente, les plaintes pleuvent en interne.
La vraie surprise est ailleurs en fait. Les plus gros gains ne viennent pas de l'écriture de code mais du débogage et du traitement des tickets Jira et Confluence, ces outils de suivi de projet que tout le monde adore détester. Le temps de codage se serait quand même amélioré de 60 %.
Et puis il y a l'effet psychologique. Avec des tokens illimités en interne, les ingénieurs ne rationnent plus leurs requêtes pour tenir le budget du trimestre, et la facture ne réserve plus de mauvaise surprise en fin de mois. Les modèles commerciaux restent accessibles pour les cas particuliers, les tâches visuelles partent par exemple chez Gemini.
Un modèle chinois au coeur d'une banque, la question fâche forcément. Abitbol balaie. Hébergés en local ou sur un cloud régional, les poids du modèle ne font selon lui courir aucun risque, le danger serait plutôt de passer par des API hébergées on ne sait où.
Les fenêtres d'un million de tokens que vendent les gros acteurs du secteur sont à ses yeux "une arnaque", 256 000 suffisent largement à coder. Tout le marché vend exactement l'inverse depuis deux ans.
Source : Theregister
Windows 11 dans une machine virtuelle sur un Mac Apple Silicon, ça se fait depuis looooongtemps avec des outils comme Parallels ou UTM. Mais tart, l'outil en ligne de commande qui crée et clone des VM comme on le ferait avec des conteneurs, n'en est pas capable, parce que la virtualisation d'Apple sur laquelle il repose ne gère officiellement que macOS et Linux.
Sauf qu'un dev nommé Mustafa Akin, vient de publier un fork qui permet d'installer Windows 11 avec tart sans un seul clic.
Je viens de le tester sur mon Mac Studio M4 Max avec l'ISO française de Windows 11 et j'ai trouvé que ça fonctionnait super, d'où ce petit tuto.
Pour vous lancer là dedans, il vous faut donc un Mac Apple Silicon sous macOS 26.6 ou 27, Xcode pour compiler tout ça, et bien sûr une ISO de Windows 11 ARM64 ( faudra vous démerder ensuite avec la licence ). Par contre, faut le savoir, ce fork repose sur deux réglages privés d'Apple, non documentés, qu'une mise à jour de macOS pourra shooter à tout moment. Donc ne montez pas votre futur homelab là dessus sans un plan de repli.
Sur son site, Mustafa Akin publie un binaire tout fait, mais j'ai préféré compiler le programme car le script de création du paquet de son fork signe proprement l'application en local avec le droit de virtualisation qui va bien.
Connexiongit clone --branch windows-guest-extras https://github.com/mustafaakin/tart.git
cd tart
git checkout e4c623c
./scripts/package-windows-preview.sh 0.1.0-windows-preview
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"
La commande export rend ce tart.app accessible au niveau du système prioritaire devant un éventuel tart déjà installé. Il ne reste alors qu'à lui passer votre ISO... tart téléchargera alors les pilotes virtio-win et WinFsp, fabriquera son propre média d'installation et démarrera Windows sans rien demander de plus.
tart create win11 --from-iso ~/Downloads/Win11_Arm64.iso
Ça m'a pris en tout et pour tout 26 minutes pour obtenir cette VM Windows fonctionnelle. Notez également que l'installation force l'anglais américain et que d'autres langues peuvent poser souci mais avec mon ISO française, l'interface est bien restée en français. Seul le clavier est resté en QWERTY au départ.
L'auteur écrit sur son blog que l'install de l'agent doit se faire manuellement pour l'instant mais ce qu'il a oublié de préciser c'est que le pilote viosock, celui qui relie le Mac à la VM, n'est pas dans la liste des pilotes que tart injecte (viostor, viogpudo, NetKVM, viorng et viofs). Résultat, chez moi, tart exec ne fonctionnait pas. Comme ce pilote se trouve dans l'ISO virtio-win que tart a gardée dans son cache, il suffit donc de le copier dans un dossier partagé, contenant l'agent publié avec la préversion :
hdiutil attach -readonly -nobrowse ~/.tart/cache/windows/sha256:303f7ae40dad495d6ae474fdc571df58958a4dbc5c37a522d80f9a203867949d.iso
mkdir -p ~/tart-share
cp -R /Volumes/virtio-win-0.1.302/viosock/w11/ARM64 ~/tart-share/viosock
hdiutil detach /Volumes/virtio-win-0.1.302
curl -L -o ~/tart-share/tart-guest-agent.exe https://github.com/mustafaakin/tart/releases/download/windows-preview-0.1.0/tart-guest-agent.exe
tart run win11 --dir=share:$HOME/tart-share
Comme la commande tart run garde la main, laissez-la tourner et ouvrez un second terminal pour la suite, en y refaisant l'export ci-dessous depuis le dossier tart, sinon vous appellerez un autre tart.
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"
Au démarrage, la session admin (mot de passe admin) s'ouvre alors toute seule et vous arrivez sur le bureau. Le dossier partagé apparaît sur le lecteur Z:, dans un dossier share. Ouvrez PowerShell en administrateur (et n'oubliez pas que le clavier est en QWERTY) pour installer le pilote, puis déclarer l'agent comme tâche lancée à l'ouverture de session, parce que c'est dans cette session que sont le presse-papiers et le bureau :
pnputil /add-driver Z:\share\viosock\viosock.inf /install
mkdir "C:\Program Files\Tart"
copy Z:\share\tart-guest-agent.exe "C:\Program Files\Tart\"
$a = New-ScheduledTaskAction -Execute "$env:SystemRoot\System32\conhost.exe" -Argument '--headless "C:\Program Files\Tart\tart-guest-agent.exe" --run-agent'
$t = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
$p = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Highest
Register-ScheduledTask -TaskName "Tart Guest Agent" -Action $a -Trigger $t -Settings $s -Principal $p
Start-ScheduledTask -TaskName "Tart Guest Agent"
Get-Service VirtioSocketWSP
Le service VirtioSocketWSP doit alors afficher Running. S'il n'existe pas, c'est que le pilote n'est pas passé et tart exec ne répondra pas. Relisez alors la sortie de pnputil et vérifiez que le dossier viosock contient bien viosock.inf.
Retournez ensuite dans le terminal du Mac et entrez cette commande pour connaitre le numéro de version du Windows :
tart exec win11 cmd /c ver
Microsoft Windows [version 10.0.26200.8037]
Informations système dans la VM : Windows 11 Famille, build 26200, sur une "Apple Virtualization Generic Platform" en ARM64
L'intérêt de tout ça c'est surtout d'avoir un Windows jetable. Vous devez arrêtez d'abord la VM de base avec tart exec win11 shutdown /s /t 0 puis pour cloner la VM, faites un : tart clone win11 w1 . C'est instantané, et y'a plus qu'à la démarrer avec un tart run w1 --no-graphics.
Avec --no-graphics ça démarre sans fenêtre et vous pouvez alors lancer ce que vous voulez avec tart exec. Ensuite pour tout stopper, un petit tart stop w1, et un tart delete w1 pour supprimer la VM et voilà...
En tout cas, n'en faites pas votre Windows de tous les jours car il n'y a ni son ni accélération graphique, pas de possibilité de suspendre le Windows et la virtualisation imbriquée se fige dès que Windows veut démarrer WSL2 ou Hyper-V.
La commande Get-Tpm confirme aussi l'absence de TPM. Et selon l'auteur, le disque est le point faible de ce Windows ARM 64 sous tart, en partie parce que tart rempli très vite les SSD avec ses logs. Pensez aussi à changer le mot de passe, puisque le compte est admin avec le mot de passe admin, et que SSH est ouvert sur le réseau interne de tart.
Mais pour tester des logiciels Windows ou scripter des trucs, ça tient bien la route.
Source : Mustafa Akin
La société de sécurité Depthfirst a publié un billet que j'ai trouvé intéressant dans lequel ils expliquent en gros que les conteneurs (Docker et compagnie) ne sont plus une barrière de sécurité suffisamment solide. La thèse du papier, c'est qu'il faut désormais partir du principe qu'un attaquant (hacker ou malware) saura sortir d'un conteneur quand il le veut, sans grande difficulté.
En effet, un conteneur comme ceux que font tourner Docker ou Kubernetes, donne à un programme l'impression d'avoir sa propre machine. Sauf qu'en réalité, il n'embarque pas de système d'exploitation. Tous les conteneurs d'un serveur passent par le même noyau Linux qui est celui de l'hôte et dont le rôle est de gérer pour eux la mémoire, le processeur ainsi que le réseau.
Toutefois, beaucoup d'organisateurs de CTF notamment s'y fient les yeux fermés et hébergent plusieurs épreuves sur le même serveur, chacune dans son conteneur, en comptant uniquement sur la sécurité de l'hôte. Mais c'est un faux sentiment de sécurité, j'en veux pour preuve ce bulletin de sécurité d'AWS daté de novembre 2025 où il est expliqué que l'entreprise ne considère plus les conteneurs comme une barrière de sécurité et ne s'en sert donc plus pour isoler ses clients les uns des autres.
Ce qui a changé depuis quelques mois, vous le savez, c'est le prix d'entrée de la recherche de failles puisqu'avec les modèles d'IA de pointe, même un attaquant avec des moyens modestes peut fabriquer sans effort, dès la publication d'une faille, un exploit contre des machines qui ne sont pas encore corrigées, alors qu'avant ça demandait de sérieuses compétences.
source : Depthfirst
Et les chiffres publiés par Depthfirst montrent que tout ça s'accélère puisque 249 CVE ont été publiées pour le noyau Linux en janvier, et en août on en a eu 1 650 !
Depthfirst relève également que sur les 36 CVE divulguées via le kernelCTF de Google, 13 sont réalisables via des interfaces ordinaires comme celles qu'un conteneur reçoit par défaut (dont les sockets locaux). En fait, on en croise sans le savoir dès qu'on passe systemd, Docker ou une base de données locale.
Le 24 juillet dernier, Depthfirst a même décroché une place au kernelCTF avec un exploit 0day (donc avant tout correctif) et aujourd'hui, le PoC est en accès libre sur GitHub. Rassurez-vous, côté noyau Linux, le correctif est sorti le 6 août mais malheureusement, côté Ubuntu la mise à jour au 24 septembre, affichait encore que le noyau de la 26.04 était en "Vulnerable, work in progress" et celui de la 24.04 en "Vulnerable". Bref, trouver des vulns ça va vite. Fixer ces vulns sur TOUTES les releases et les machines, ça prend du temps. Alors qu'avant c'était l'inverse. Bref, tout a été chamboulé et c'est un peu la merde maintenant niveau cybersécurité pour patcher rapidement.
Alors comment se protéger de tout ça ?
Hé bien la solution de Depthfirst va vous mettre en PLS car eux proposent carrément de ne plus partager le noyau. Ils recommandent à la place de migrer les charges non fiables vers des microVM, autrement dit des machines virtuelles légères où chaque charge aura son propre noyau. Le projet Firecracker en fait partie tout comme Kata Containers comme ça, en théorie, si un attaquant casse l'un de ces noyau, il ne compromet que sa propre instance et pas l'hôte dans son entièreté ni ses voisins.
Reste que Firecracker s'appuie sur KVM, la brique de virtualisation du noyau Linux de l'hôte. Et comme vous le savez, KVM a eu ses propres failles. En effet, cet été, la faille Januscape ouvrait en grand la porte de la machine physique à un attaquant pourtant enfermé dans sa VM, à condition bien sûr que l'hôte autorise la virtualisation imbriquée (une VM dans la VM). Alors certes, la surface d'attaque est plus petite mais loin d'être nulle.
Voilà, en attendant, si vous êtes sous Ubuntu 24.04 ou 26.04, surveillez bien la mise à dispo du prochain noyau. Canonical a d'ailleurs annoncé il y a peu, une publication hebdomadaire des noyaux pour tenter de compenser cet emballement.
Source : le billet de recherche de depthfirst
Si vous développez pour AWS, il y a de bonnes chances que LocalStack tourne déjà quelque part dans votre docker-compose ou votre CI. C'est un peu l'outil incontournable pour tester ses buckets S3 et ses fonctions Lambda sans avoir à toucher au vrai cloud. Sauf que depuis mars dernier, ses nouvelles versions exigent un compte LocalStack et un jeton d'authentification, CI comprise, et surtout l'édition Community n'est plus prise en charge.
Ouin !
Et comme si ça ne suffisait pas, l'offre gratuite qui reste interdit totalement l'usage commercial. Donc si vous l'utilisez dans le cadre de votre travail, faudra passer à la caisse. Alors, oui, ne pas respecter la licence ou se figer sur une ancienne image reste possible, mais déjà, ça ne se fait pas, et ensuite, niveau faille de sécu, ce n'est pas top.
Mais c'est là qu'arrive en sauveur Floci, un émulateur AWS local sous licence MIT qui se présente comme un remplaçant direct de LocalStack, sans avoir besoin de se créer un compte ou un jeton et surtout sans offre payante planquée dedans.
Maintenant, le principe reste le même puisque vous pointez dessus l'AWS CLI (Floci écoute sur le port 4566), vos SDK, Terraform, OpenTofu ou le CDK, avec la région de votre choix et des identifiants bidon, et vos commandes habituelles tomberont sur votre machine au lieu de partir chez Amazon.
Le plus simple pour démarrer, c'est sa CLI qu'on peut déployer avec Homebrew (il y a aussi un script pour Linux et un pour Windows) :
brew install floci-io/floci/floci
floci start
eval $(floci env)
aws s3 mb s3://my-bucket
Ensuite, faites un floci start pour lancer l'émulateur dans un conteneur et lui monter le socket Docker de votre machine. Floci s'appuie sur de vrais conteneurs dès que la fidélité l'exige ce qui fait que Lambda tourne dans l'image d'exécution officielle d'AWS, RDS lance un vrai PostgreSQL, MySQL ou MariaDB, ElastiCache un Valkey, et c'est pareil pour ECS, EC2 ou EKS.
J'ai fait l'essai sur mon Mac avec un bucket S3, une table DynamoDB et une petite fonction Lambda en Python, et tout a répondu du premier coup à la CLI AWS. La Lambda a juste mis six secondes à répondre au premier appel, puis moins d'une seconde au suivant.
Pour voir ce qui se passe ensuite, une console web est dispo localhost:4566/_floci/ui, avec vos ressources rangées par service.
La console web de Floci sur localhost, après un essai sur S3, DynamoDB et Lambda
Notez aussi que si vous venez de LocalStack, la bascule se résume simplement dans le nom de l'image puisque Floci traduit tout seul les variables d'environnement de LocalStack, exécute sans modification les scripts d'init rangés dans /etc/localstack/init/ et répond même sur /_localstack/health. Cela veut dire qu'une CI qui attend ce signal ne voit pas la différence et ça c'est super cool pour migrer vite fait bien fait.
Et si vos scripts appellent aws ou boto3, prenez l'image floci/floci:latest-compat, qui embarque les deux.
Par contre, méfiez-vous du volume de données, car LocalStack range tout par défaut dans /var/lib/localstack et Floci dans /app/data. Donc dans le docker compose, pointez bien votre volume sur /app/data sinon, vous perdrez vos fichiers au premier restart du docker.
Après n'oubliez pas non plus que Floci imite le comportement d'AWS, et pas sa sécurité. En effet, par défaut, il n'applique aucune politique IAM, donc si vous voulez vérifier qu'un rôle trop resserré bloque bien une action, il faudra activer la variable FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLED. Et certains services ne sont également que des façades. Par exemple Bedrock Runtime renvoie des réponses factices et Transcribe termine ses tâches aussitôt, sans jamais traiter l'audio, donc oui, votre code peut les appeler, mais le résultat ne sera pas au rendez-vous, ce qui est tout à fait normal.
Pour le reste, les données sont stockées en mémoire par défaut et s'effaceront à l'arrêt, ce qui est pile poil ce qu'on veut en CI. Vous pouvez quand même le paramétrer pour que ça s'écrive sur le disque si vous voulez...
Voilà, à essayer sur une branche de votre CI si vous voulez vous débarrasser de débrancher LocalStack pour de bon !
Source : Floci sur GitHub
"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !
Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.
Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.
Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.
Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.
Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.
Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.
Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...
Les entreprises déploient leurs premiers agents et découvrent aussi comment gouverner les interactions entre les modèles, les applications et les données ?
Une nouvelle catégorie de logiciels, les AI Gateways, ambitionne de devenir le point de contrôle de ces architectures. À l’image des API Gateways il y a vingt ans, cette couche pourrait redéfinir la manière dont les DSI construiront leurs infrastructures d’intelligence artificielle. A condition qu’elle tienne ses promesses.
L’histoire des systèmes d’information est jalonnée de ruptures technologiques qui ont progressivement fait apparaître de nouvelles couches d’infrastructure.
Au début des années 1990, la priorité était de connecter les réseaux tout en les protégeant : les pare-feu sont devenus le point de passage obligé entre l’entreprise et Internet.
Au début des années 2000, la généralisation des architectures orientées services puis des microservices a fait émerger une autre nécessité : contrôler les échanges entre applications. Les API Gateway se sont imposées pour authentifier les appels, appliquer des politiques de sécurité et fournir une visibilité centralisée.
Une décennie plus tard, l’explosion du cloud a donné naissance aux plateformes IAM modernes, aux CASB (Cloud Access Security Broker) aux solutions SASE et aux plateformes CNAPP (Cloud-Native Application Protection Platform, des outils de sécurisation des applications cloud) pour répondre à de nouveaux besoins de gouvernance.
L’IA générative semble suivre le même chemin. Après une première phase centrée sur le choix d’un modèle de langage performant, les entreprises découvrent qu’elles doivent désormais administrer un écosystème où plusieurs modèles coexistent, où des agents IA prennent des décisions, et où les interactions avec le système d’information deviennent plus nombreuses et plus dynamiques.
Entre 2023 et 2024, la plupart des expérimentations reposaient sur un seul fournisseur : une application appelait un modèle via une API, point final. Cette architecture reste simple.
En 2026, le changement d’échelle est net. Selon une analyse de Vercel portant sur les usages en production, la part des équipes exploitant cinq modèles ou plus est passée de 29 % à 37 % en un an. Un basculement structurel plutôt qu’un ajustement marginal.
Un assistant bureautique peut désormais mobiliser un modèle propriétaire pour la génération de texte, un modèle open source exécuté localement pour des traitements confidentiels, un modèle spécialisé pour l’analyse documentaire et un moteur multimodal pour l’image ou la vidéo.
Cette diversification répond à trois logiques :
Cette évolution fait apparaître une difficulté nouvelle : comment administrer un environnement où plusieurs modèles sont utilisés simultanément par des centaines d’applications, sans multiplier les clés d’API et les intégrations ad hoc ?
La généralisation des agents constitue un second facteur de rupture.
Un chatbot traditionnel répond à une question. Un agent peut planifier une série d’actions : consulter une base documentaire, interroger un ERP, créer un ticket dans un outil ITSM, envoyer un courriel, puis transmettre le résultat à un autre agent. Il ne produit plus seulement une réponse : il agit.
Pour les équipes d’architecture, cela change la nature des flux. Les échanges ne s’effectuent plus uniquement entre applications connues : ils impliquent des composants capables de choisir eux-mêmes quels outils utiliser selon le contexte.
Le protocole MCP (Model Context Protocol), qui standardise la façon dont un modèle accède à des outils externes et structure une bonne partie de ces échanges. Cependant, son adoption rapide crée aussi une nouvelle surface d’exposition, puisque chaque connecteur MCP est potentiellement une porte d’entrée vers un système interne.
Dans de nombreuses entreprises, chaque application dialogue encore directement avec le modèle retenu par son équipe de développement. Cette approche fonctionne tant que les projets restent peu nombreux mais elle devient difficile à maintenir dès que plusieurs dizaines d’applications utilisent plusieurs fournisseurs. Chaque équipe doit alors gérer séparément les clés d’API, les politiques de sécurité, les limites de consommation, la journalisation, les changements de version des modèles et les règles de conformité propres à chaque fournisseur.
Plus le nombre d’agents augmente, plus le nombre d’interactions explose, avec un risque bien connu : la multiplication incontrôlée de connexions point à point, que l’histoire des systèmes d’information a déjà vu se reproduire à chaque rupture technologique.
Concrètement, une AI Gateway se place comme un proxy entre les applications et les fournisseurs de modèles (OpenAI, Anthropic, Google, Azure, modèles open source auto-hébergés).
Elle expose un point d’entrée unique et ajoute, selon les offres, du routage multi-modèle, du failover automatique en cas de panne d’un fournisseur, du cache sémantique pour réduire coûts et latence sur des requêtes similaires, des quotas et budgets par équipe ou par utilisateur, de la journalisation au niveau du token, ainsi que des fonctions de sécurité comme le masquage de données personnelles ou la détection de tentatives d’injection de prompt.
Le marché s’est structuré très vite en 2026, avec des positionnements différenciés :
| Acteur | Positionnement | Point d’attention |
|---|---|---|
| LiteLLM | Proxy Open Source auto-hébergé supportant +100 fournisseurs. Idéal pour garder le contrôle total des données. | Charge d’exploitation interne élevée ; vulnérabilité supply chain identifiée début 2026. |
| Portkey | Gouvernance, observabilité et sécurité avancées pour environnements très réglementés. | Racheté par Palo Alto Networks (mai 2026) : évolution produit et politique tarifaire à suivre. |
| Cloudflare / Vercel | Integration native à l’infrastructure edge existante avec très peu d’effort de déploiement. | Couplage fort à leur écosystème cloud respectif (risque de vendor lock-in). |
| Kong AI Gateway | Extension d’une API Gateway entreprise établie, unifiant trafic REST classique, IA et protocole MCP. | Infrastructures parfois lourdes si l’entreprise ne possède pas déjà l’écosystème Kong. |
| TrueFoundry / Bifrost / Helicone | Pure-players spécialisés sur des niches (souveraineté des données, ultra-basse latence, observabilité). | Acteurs de taille plus modeste avec risque fort de consolidation ou de rachat à court terme. |
Cette diversité montre que le terme « AI Gateway » recouvre encore des réalités différentes selon l’éditeur : certains sont d’abord des routeurs de coûts, d’autres des plateformes de gouvernance, d’autres des extensions d’API Gateway existantes.
Gartner a publié en 2025 et 2026 plusieurs travaux dédiés (Market Guide for AI Gateways et Market Overview actualisé en 2026) qui positionnent cette couche comme un composant des futures architectures d’IA d’entreprise, chargé de gérer les connexions vers les services d’IA, d’appliquer des politiques de sécurité, de répartir les requêtes entre plusieurs modèles et d’améliorer la visibilité sur les coûts.
Le cabinet inscrit plus largement l’AI Gateway dans son cadre AI TRiSM (Trust, Risk and Security Management), dont il estimait le marché à environ 3,1 milliards $en 2025, avec une croissance annuelle projetée de l’ordre de 35 % jusqu’en 2030. Un chiffre à prendre comme un ordre de grandeur d’analyste plutôt qu’une certitude, la firme elle-même révisant régulièrement ses prévisions à mesure que le marché se consolide.
Le NIST AI Risk Management Framework converge sur le fond. Sans employer le terme « AI Gateway », il insiste sur la nécessité de mécanismes de gouvernance, de traçabilité et de surveillance continue tout au long du cycle de vie des systèmes d’IA. Des fonctions qu’une gateway peut techniquement porter, sans que le référentiel ne prescrive cette architecture en particulier.
La Cloud Security Alliance défend une lecture proche, estimant que la gouvernance de l’IA ne peut plus être traitée uniquement au niveau applicatif.
L’argument réglementaire mérite d’être précisé, car le calendrier a changé courant 2026.
Le paquet Digital Omnibus, adopté définitivement fin juin 2026, a reporté au 2 décembre 2027 la plupart des obligations pesant sur les systèmes à haut risque de l’annexe III (recrutement, crédit, éducation, justice, biométrie). Reste en vigueur au 2 août 2026 l’essentiel des obligations de transparence de l’article 50 : informer les utilisateurs qu’ils interagissent avec une IA, et identifier les contenus générés ou modifiés par IA.
Pour les systèmes qui resteront soumis au régime haut risque, l’article 12 impose une journalisation automatique et infalsifiable des événements, avec une conservation minimale de six mois (vingt-quatre mois pour la biométrie), et l’article 14 exige une supervision humaine effective.
Ce sont précisément les fonctions ( journalisation centralisée, traçabilité au niveau de chaque appel et points de contrôle humain ) qu’une AI Gateway peut industrialiser à l’échelle de dizaines d’applications, plutôt que de les faire reconstruire par chaque équipe projet. Le règlement précise aussi, dans ses considérants 99 et 100, que dans une chaîne d’agents IA, l’obligation de conformité s’étend à chaque agent exécutant une fonction à haut risque. Un argument de poids pour centraliser la gouvernance plutôt que de la disperser.
Le report ne change donc pas la logique de fond : il retire simplement l’urgence à très court terme, sans annuler la nécessité d’anticiper une architecture capable de produire ces preuves de conformité.
Cette convergence d’analyses ne doit pas masquer les zones d’incertitude.
Un marché encore jeune et instable. Le rachat de Portkey par Palo Alto Networks, l’incident de sécurité touchant LiteLLM et le nombre élevé d’éditeurs recensés (plus de 160 selon certains annuaires spécialisés) suggèrent une consolidation rapide plutôt qu’un marché mature. Une DSI qui adopte aujourd’hui une gateway prend un pari sur la pérennité de son éditeur.
Un nouveau point de défaillance unique. Concentrer tout le trafic IA sur une seule couche crée mécaniquement un single point of failure : si la gateway tombe, c’est l’ensemble des applications IA de l’entreprise qui s’arrête, même si les modèles sous-jacents fonctionnent normalement.
Une latence ajoutée, mais généralement marginale. Plusieurs comparatifs indépendants estiment le surcoût d’une gateway bien opérée à quelques millisecondes à quelques dizaines de millisecondes. Ceci est négligeable face à un appel de modèle qui dure plusieurs secondes, sauf en cas de mauvaise implémentation.
Une frontière floue avec l’existant. Une partie des fonctions revendiquées (authentification, quotas, logs) peut aussi être portée par une API Gateway classique déjà en place, ce qui pose la question : faut-il une brique dédiée ou une extension de l’infrastructure API existante ? Les offres de type Kong ou Zuplo, qui fusionnent les deux mondes, illustrent que la frontière entre « API Gateway » et « AI Gateway » n’est pas encore stabilisée.
Le risque de gouvernance en façade. Une gateway journalise et contrôle les flux, mais elle ne résout pas à elle seule les causes profondes des incidents d’IA en entreprise. Gartner estime qu’une large majorité des transactions IA non autorisées proviennent de mauvais usages internes plutôt que d’attaques malveillantes. Un problème davantage organisationnel que technique, qu’un outil ne suffit pas à traiter.
L’histoire des pare-feu, des API Gateway puis des CASB montre que ces couches d’infrastructure, une fois qu’elles s’imposent, deviennent difficiles à retirer.
Pour une DSI qui déploie aujourd’hui plusieurs modèles et commence à expérimenter des agents, la question n’est plus de savoir si une gouvernance centralisée sera nécessaire, mais quand l’introduire et avec quel degré de couplage à l’infrastructure existante.
Un point de départ raisonnable consiste à cartographier les usages IA actuels et à venir, à évaluer si une extension de l’API Gateway déjà en place suffit à court terme, et à ne s’engager sur un éditeur dédié qu’après avoir mesuré son modèle de sécurité, sa pérennité financière et le degré de lock-in qu’il introduit.
Dans un marché qui se consolide aussi vite qu’il grossit, la prudence sur le choix du fournisseur compte au moins autant que la décision d’adopter la brique elle-même.
Sources :
> Gartner (Market Guide for AI Gateways, 2025 ; Market Overview for AI Gateways, 2026 ; Market Guide for AI Trust, Risk and Security Management, 2025
> NIST AI Risk Management Framework 1.0
> Cloud Security Alliance
> Règlement (UE) 2024/1689 (AI Act)
> Paquet Digital Omnibus adopté fin juin 2026
The post AI Gateway : la prochaine bataille des infrastructures IA appeared first on Silicon.fr.
GitLab a sorti hier (lundi 17 août), un correctif d'urgence , complètement en dehors de son calendrier habituel, pour une faille qui permet à quelqu'un sans compte ni mot de passe de modifier ou de supprimer vos projets publics et des données utilisateur. Hé ouais c'est chaud et c'est pour ça que son score CVSS est de 9,4 sur 10.
5 jours plus tôt, le 12 août, GitLab publiait son patch de routine pour la 19.2, 19.1 et 19.0. C'est un périmètre normal puisque sa politique de maintenance ne couvre que la version stable et les deux précédentes. Mais comme là, on est dans l'exceptionnel, ce correctif du 17 août en couvre une quatrième, la 18.11, dont le support avait pris fin le 16 juillet dernier. Ils sont allés rouvrir une branche morte juste pour patcher ce GROS problème !
La faille elle-même, on n'en sait presque rien par contre. Estampillée CVE-2026-19478, c'est une histoire de directive GraphQL, mais GitLab ne dit ni laquelle, ni dans quelles conditions ça se déclenche. Les détails techniques sortiront vers la mi-novembre, c'est-à-dire 90 jours après le correctif, comme d'habitude, histoire d'être sûr que tout le monde ait patché son install.
Maintenant, la bonne nouvelle c'est que si vous êtes sur GitLab.com ou sa version Dedicated , vous n'avez rien à faire, puisque c'est déjà patché. En fait cette histoire ne concerne que les instances auto-hébergées.
Et parmi elles, tout le monde n'est pas impacté de la même manière. En effet, le vecteur d'attaque passe par le réseau et vise les projets publics. Cela veut dire que votre instance planquée derrière un VPN, sans visibilité publique, risque beaucoup moins que celle qui expose ses dépôts à Internet.
Ensuite, pour la mise à jour, ça dépend d'où vous partez. Entre la 18.2 et la 18.10, aucun correctif n'existe sur votre branche. Il faudra upgrader jusqu'à la 18.11.11, en vous arrêtant aux paliers de 18.5 et 18.8 s'ils sont sur votre route.
Si vous tournez déjà en 18.11, prenez la 18.11.11. Sur une 19, c'est 19.0.8, 19.1.6 ou 19.2.4. Et plus ancien que 18.2 ? Bah là, GitLab ne liste pas ces versions parmi les affectées, mais elles ne reçoivent plus de correctif depuis un bon moment, donc ce serait bien de mettre à jour quand même, hein...
Pour le moment, personne n'a signalé d'attaque et aucun exploit ou PoC n'a fait surface sur GitHub. Ça ne veut pas dire grand-chose, je vous l'accorde mais on se rassure comme on peut...
Allez, bon courage !
Source : The Hacker News
Cloudflare Computer est un projet qui donne à votre agent IA un endroit rien qu'à lui. C'est-à-dire un vrai système de fichiers, avec des dossiers, des fichiers qui restent, et de quoi lancer des commandes dedans. Bref, un vrai poste de travail que l'agent garde entre deux sessions, au lieu de repartir de zéro à chaque fois, puisque tous les fichiers sont rangés dans une base SQLite.
Le système de fichiers s'utilise ensuite comme n'importe quel autre. Lire, écrire, créer un dossier, lister, supprimer, et un grep intégré pour fouiller dans le tas. Pour tout le reste, il n'y a qu'une fonction à retenir, exec(). Vous lui passez une commande, et elle vous rend la sortie et le code de retour.
Ce qui change par contre, c'est l'endroit où la commande tourne. 3 environnements sont disponibles et interchangeables sur les mêmes fichiers. Il y a d'abord un conteneur Linux complet, avec npm, node et de vrais binaires. Ou un shell léger pour les commandes simples. Et enfin, un dernier qui exécute directement votre code, sur une base neuve à chaque appel.
Comme ça, vous passez de l'un à l'autre sans réécrire une ligne de votre agent.
Les 9 exemples fournis montrent bien ce qu'on peut en tirer quand on aime bidouiller. Le plus parlant fait par exemple tourner un agent de discussion qui prendra l'espace de travail comme répertoire courant, donc qui travaillera dans de vrais fichiers au lieu de tout garder en mémoire.
Un autre colle pandoc dans le conteneur et laisse l'agent transformer une fiche markdown en PDF. Il y en a aussi un qui fabrique des images avec Workers AI, un quatrième joue sur les politiques de sortie réseau pour décider ce que l'agent a le droit de joindre, et enfin, un dernier génère un projet Worker complet, puis le publie.
Il y a même une interface web qui balance la même tâche dans le conteneur et dans un environnement léger, côte à côte.
Reste à savoir ce qui est gratuit là-dedans... Le code est sous licence MIT, et le système de fichiers seul, sans aucune exécution, tourne sans souci dans le plan Workers gratuit puisque les Durable Objects qui portent ce stockage y sont inclus, avec 100 000 requêtes par jour et 5 Go d'espace.
Il faut un compte Cloudflare, évidemment...
Puis si vous voulez faire tourner des vraies commandes ou avoir un shell, faudra payer puisque le conteneur comme les environnements légers réclament le plan Workers payant, facturé 5 dollars par mois au minimum.
Après j'ai quelques réserves quand même parce que le projet est très récent, encore en preview et clairement inadapté à de la production. Ensuite, la limite technique d'un espace de travail tourne autour de 10 Go, et les accès disque lourds restent plus lents que sur un vrai disque. Puis surtout, tout vit chez Cloudflare, et pas chez vous (si vous préférez l'inverse, je vous avais montré workerd , le moteur des Workers en local).
Mais bon, c'est à garder à l'œil si vous êtes client Cloudflare.
Gérer un serveur à la main, c'est nginx à configurer, les certificats à renouveler, les sauvegardes à planifier et les conteneurs à surveiller... C'est beaucoup de travail. Mais vous allez avoir de l'aide grâce à DockPanel, d'Ovidiu Drobotă, qui met tout ça derrière une jolie interface web tenant dans 19 Mo de RAM.
L'installation se colle en une ligne sur un VPS frais et vous récupérez un panneau d'admin sur le port 8443. Ubuntu, Debian, Rocky, Fedora ou Amazon Linux, en x86_64 comme en ARM64.
À partir de là vous créez des sites en PHP, Node ou Python, avec nginx configuré tout seul et les certificats Let's Encrypt qui se renouvellent sans y penser. Les bases MySQL et PostgreSQL vont avec, navigateur SQL intégré et restauration à un instant T via les journaux binaires.
Ensuite, c'est surtout le catalogue Docker qui fait le gros du travail. Environ 150 modèles en un clic répartis sur 14 catégories, WordPress, Postgres, Grafana, n8n ou Immich, et le reverse proxy, le SSL et le réseau se câblent automatiquement derrière. Les conteneurs inactifs peuvent même se mettre en veille tout seuls pour libérer la machine.
Je vous parlais l'an dernier de Coolify pour le déploiement en self-hosted , et avant ça de aaPanel, le clone gratuit de cPanel mais aucun des deux ne couvre autant de terrain.
Côté déploiement, vous poussez votre code et ça part en production, avec bascule atomique par lien symbolique et retour arrière en un clic quand le déploiement du vendredi tourne mal. Nixpacks reconnaît plus de 30 langages, donc pas de Dockerfile à écrire, et chaque branche peut avoir son environnement de préversion.
Il y a aussi un serveur mail complet, Postfix, Dovecot et DKIM, avec Roundcube en webmail et Rspamd contre le spam. La partie DNS pilote Cloudflare et PowerDNS, avec vérification de propagation, DNSSEC et les tunnels Cloudflare. Un module CDN gère BunnyCDN et Cloudflare, purge du cache comprise.
Pour la surveillance, des sondes HTTP, TCP et ping, une gestion d'incidents avec chronologie et post-mortem, une page de statut publique à laquelle vos utilisateurs peuvent s'abonner, et des alertes qui partent sur Slack, Discord ou PagerDuty. Un point de collecte Prometheus est dispo, avec un tableau Grafana prêt à importer.
La sécurité est activée par défaut avec pare-feu applicatif ModSecurity par site, Fail2Ban, durcissement SSH en un clic, connexion par passkey ou 2FA, et chaque image Docker déployée peut être scannée à la recherche de CVE avec grype, avec refus de déploiement au-dessus du seuil que vous fixez. Les sauvegardes passent par Restic, chiffrées et dédupliquées, vers S3, SFTP, B2 ou GCS, avec vérification de restauration.
Le reste ensuite, c'est que du confort. Terminal web avec enregistrement de session, gestionnaire de fichiers, palette de commandes en Ctrl+K, 6 thèmes, boîte à secrets chiffrée, passerelle à webhooks et une ligne de commande. La configuration complète s'exporte en YAML pour être rejouée ailleurs. Si vous gérez plusieurs machines, un seul panneau les pilote toutes, avec des comptes revendeur en marque blanche pour ceux que ça intéresse.
Deux choses à savoir avant de lancer l'installation quand même... En mars, une injection de commande dans le formulaire de création de site a permis à un visiteur de passer root sur la machine de l'auteur. C'est corrigé depuis, mais l'agent tourne en root par conception puisque c'est lui qui touche à Docker, à nginx et aux certificats.
L'autre point, c'est la licence. DockPanel est en Business Source License 1.1, ce qui n'est pas de l'open source même si la page d'accueil le présente comme ça. L'usage est libre et gratuit sur vos propres serveurs, mais la revente en service hébergé est interdite. Une bascule en MIT est quand même programmée pour mars 2030.
Voilà, je me suis dit que ça pourrait vous intéresser.
Pendant une décennie, la centralisation dans le cloud a été le réflexe dominant. Mais un déluge de données générées sur le terrain – capteurs, machines, caméras, objets connectés – met ce modèle à l’épreuve. Selon Gartner, environ 75 % des données générées par les entreprises sont désormais produites et traitées en dehors d’un data center centralisé.
La cause est physique autant qu’économique. Le nombre d’objets connectés a dépassé 15 milliards d’unités dans le monde en 2024 et pourrait atteindre près de 30 milliards d’ici 2030. Faire transiter toutes ces données vers un cloud central engendre des coûts de bande passante, des délais et une dépendance à la connexion réseau que de nombreux usages ne tolèrent pas.
Trois limites apparaissent clairement. La latence : certaines applications (robot industriel, véhicule autonome, contrôle qualité par vision) exigent des réponses en quelques millisecondes, incompatibles avec un aller-retour vers un data center lointain. Les coûts : transférer et stocker des volumes massifs au loin coûte cher. La résilience : une activité critique ne peut s’arrêter à chaque coupure réseau.
À ces limites s’ajoute la souveraineté. Certaines données sensibles – santé, défense, secrets industriels – ne peuvent ou ne doivent pas quitter un site ou un territoire donné, pour des raisons réglementaires ou stratégiques. Les traiter localement, en périphérie, plutôt que de les exporter vers un cloud central potentiellement soumis à des lois extraterritoriales, devient un argument de plus en faveur d’une architecture distribuée. Latence, coût, résilience et souveraineté convergent ainsi pour remettre en cause le réflexe du « tout au cloud ».
L’edge computing (informatique en périphérie) consiste à traiter la donnée au plus près de sa source, plutôt que de tout envoyer vers un cloud central. Un serveur local, une passerelle IoT ou un équipement durci analyse les données sur place, ne remontant vers le cloud que l’essentiel – résultats, agrégats, alertes.
Les bénéfices sont directs. La latence chute, permettant des réponses en temps réel ; les besoins en bande passante diminuent, puisque seules les données utiles remontent ; et l’activité continue de fonctionner même en cas de coupure réseau, gage de résilience. Dans l’industrie, des passerelles en périphérie peuvent réduire la latence de plus de moitié et diminuer fortement la dépendance au cloud.
L’edge n’est pas une mode mais une lame de fond, portée par l’industrie 4.0, l’IoT et l’IA. Les dépenses mondiales liées à l’edge computing croissent d’environ 13 % par an et pourraient atteindre 317 milliards de dollars en 2026. La maintenance prédictive, la supervision locale, l’analyse vidéo ou les systèmes autonomes en sont les cas d’usage emblématiques.
L’usine est l’illustration la plus parlante de cette bascule. Une ligne de production moderne génère un déluge de données – capteurs sur les machines, caméras de contrôle qualité, robots collaboratifs – qu’il serait absurde et risqué de faire transiter intégralement vers un cloud distant. Traiter ces flux sur place permet de détecter un défaut en temps réel, d’arrêter une machine avant la casse ou de guider un robot, sans dépendre d’une connexion. C’est dans ces environnements physiques et critiques que l’edge démontre le plus clairement sa valeur.
L’edge ne remplace pas le cloud : les deux se complètent. Le cloud excelle pour le stockage à grande échelle, l’analytique avancée et l’entraînement des modèles d’IA ; l’edge pour le traitement local, rapide et résilient. La bonne architecture n’est ni « tout cloud » ni « tout edge », mais un continuum où chaque donnée est traitée à l’endroit le plus pertinent.
C’est la définition même de l’environnement hybride : une infrastructure combinant cloud public, ressources privées ou sur site, et edge, orchestrés ensemble. Pour l’industrie comme pour les services, l’enjeu de 2026 n’est plus de choisir un camp, mais de concevoir cette architecture distribuée et de l’orchestrer intelligemment.
Cet arbitrage dépasse la seule technique. Il touche aux coûts (l’edge demande un investissement matériel initial mais réduit les coûts récurrents), à la résilience (continuité d’activité), et à la souveraineté (traiter localement des données sensibles plutôt que de les exporter). Il devient un levier de compétitivité et un sujet de direction, pas seulement de DSI.
Aborder les environnements hybrides et l’edge ne suppose pas de tout transformer d’emblée. L’approche éprouvée est progressive :
L’enjeu pour un dirigeant n’est pas d’opposer cloud et terrain, mais d’orchestrer le continuum entre les deux. À mesure que les données naissent en périphérie et que l’IA s’invite jusque dans les ateliers, la capacité à traiter chaque flux au bon endroit devient déterminante pour la performance, la résilience et la souveraineté. Les environnements hybrides ne sont pas une complexité subie de plus : bien conçus, ils sont la réponse architecturale à un monde où la donnée ne vit plus seulement dans le nuage.
Un dernier point mérite l’attention : l’edge est aussi un facilitateur de l’IA sur le terrain. Faire tourner un modèle d’IA directement en périphérie – pour analyser un flux vidéo, détecter une anomalie sur une machine ou guider un robot – suppose une capacité de calcul locale que seul l’edge procure. À mesure que l’IA se diffuse dans les opérations physiques, la maîtrise de l’edge conditionne la capacité à en tirer parti. Cloud et edge ne sont donc pas concurrents mais les deux faces d’une même infrastructure moderne, où l’intelligence se déploie du centre jusqu’à la périphérie.
Ce contenu est publié par Mentioned
The post Gérer son infrastructure entre cloud et terrain : l’enjeu des environnements hybrides et de l’edge appeared first on Silicon.fr.
