Pourquoi isoler l'IA de la plateforme
UNE SURFACE D'ATTAQUE PARTAGÉE Sur un même système, l'IA et la plateforme partagent le noyau, les utilisateurs, le disque, les sockets. Une IA est pilotée par du texte : une injection de consigne cachée dans un fichier qu'elle lit peut détourner ses outils. S'il n'y a aucune frontière, ce détournement atteint directement les fichiers, les secrets et les processus de la plateforme. Le périmètre à défendre n'est plus la plateforme seule, mais la plateforme PLUS tout ce que l'IA peut faire.
LA CONFUSION DES PRIVILÈGES Une IA utile a besoin de droits larges : lire et écrire des fichiers, exécuter des commandes, joindre le réseau. Une plateforme en production a besoin de l'inverse : le strict minimum, cloisonné. Sur un seul hôte on ne peut pas satisfaire les deux — soit on sur-autorise la plateforme pour laisser travailler l'IA, soit on bride l'IA au point de la rendre inutile. Le principe du moindre privilège devient inapplicable.
L'EXFILTRATION DE SECRETS Clés privées, base de données, fichiers de configuration, jetons : sur le même hôte, tout cela est sur un disque que l'IA peut lire. Il suffit d'une consigne malveillante glissée dans n'importe quelle donnée qu'elle traite pour que ces secrets partent ailleurs — un message, un journal, un dépôt. Une fuite de clé de signature ou de base n'est pas un bogue à corriger : c'est un incident de sécurité qui impose une rotation complète.
LA CONTENTION DE RESSOURCES L'inférence d'un modèle, un build, une indexation : ce sont des charges lourdes en processeur, mémoire et entrées-sorties. Sur un hôte partagé, elles entrent en concurrence directe avec la plateforme : latence qui grimpe, mémoire épuisée (le système tue des processus), disque sous pression. Un simple pic d'activité de l'IA devient un incident de disponibilité pour les vrais utilisateurs.
LA CHAÎNE D'APPROVISIONNEMENT Une IA tire des modèles, des bibliothèques, des outils, parfois depuis l'extérieur. Chacun devient une dépendance de plus SUR L'HÔTE de la plateforme, à faire confiance et à auditer. La surface d'approvisionnement de la plateforme — normalement réduite et figée — se met à croître au rythme des besoins de l'IA, et il devient impossible de dire précisément ce qui tourne à côté du service.
LA FRONTIÈRE D'AUDIT BROUILLÉE Journaux, processus, connexions réseau de l'IA et de la plateforme s'entremêlent sur un seul hôte. Après un incident, attribuer une action devient difficile, et surtout : on ne peut plus prouver simplement que la plateforme n'a pas été touchée. L'isolation, elle, donne une réponse nette — l'IA n'a jamais eu d'accès autre que l'API publique, point.
LE RAYON D'EXPLOSION Une commande de suppression trop large, une boucle qui s'emballe, une migration hasardeuse lancée par l'IA : sur un hôte partagé, cela frappe le même disque et la même base que la production. Il n'y a pas de mur coupe-feu entre « le bac à sable de l'IA » et « le service ». Le rayon d'explosion d'une simple bévue est maximal.
LA BONNE PRATIQUE : L'ISOLATION L'IA vit sur un hôte séparé (machine, VM ou conteneur dédié), avec son propre utilisateur, son segment réseau, et AUCUN accès aux secrets ni aux données de la plateforme. Elle n'atteint la plateforme que par son API publique et authentifiée — exactement comme n'importe quel client. C'est la règle « l'IA peut entrer, pas être incluse » : elle agit sous les permissions d'un compte, rien n'est exfiltré, elle n'est jamais dans le cœur du logiciel.
Balayez vers la gauche ou la droite, ou utilisez les flèches du clavier, pour parcourir les images. Appuyez sur Échap pour fermer.