Pendant des décennies, le Shadow IT se résumait à des applications SaaS non approuvées ou à des serveurs de stockage personnels. Aujourd’hui, le phénomène a muté en une force bien plus disruptive : le Shadow AI. Le constat est sans appel : alors que les directions informatiques s’interrogent encore sur les protocoles, les collaborateurs, eux, ont déjà intégré l’IA générative dans leur quotidien.

Selon les analystes de Forrester, le « Bring Your Own AI » (BYOAI) est devenu la norme, car les employés privilégient l’efficacité immédiate à la conformité procédurale.

Pour le DSI, l’enjeu dépasse la simple gestion de parc logiciel. Il s’agit désormais de protéger la propriété intellectuelle tout en ne devenant pas le goulot d’étranglement de la productivité. Comme le souligne Gartner, « le Shadow AI est le résultat d’un décalage entre la vitesse de l’innovation en IA et la vitesse de la gouvernance informatique. »

Sortir de l’illusion du blocage

Le premier réflexe de nombreuses organisations a été la restriction pure et simple. Pourtant, cette stratégie est aujourd’hui jugée non seulement inefficace, mais dangereuse. En bloquant l’accès aux LLM (Large Language Models) sur le réseau d’entreprise, la DSI ne supprime pas l’usage ; elle le rend invisible. Les collaborateurs se tournent vers leurs terminaux personnels, créant une zone grise où aucune politique de sécurité ne s’applique.

Cette transition impose au DSI d’évoluer vers un rôle de « facilitateur de confiance ». L’idée maîtresse est de passer d’une gouvernance prohibitive à une gouvernance adaptative. Michele Goetz, analyste chez Forrester, résume parfaitement cette bascule : « La gouvernance ne consiste pas à dire non, elle consiste à définir comment. »

Au-delà de la fuite de données, le risque majeur réside dans la fragmentation technologique. Si chaque département adopte son propre outil d’IA de manière isolée, l’entreprise se retrouve face à une explosion de la dette technique et une incapacité totale à harmoniser ses processus. Le rôle du DSI est donc de centraliser cette demande diffuse pour proposer des solutions qui répondent aux besoins métiers tout en garantissant l’auditabilité des décisions prises par l’IA.

Éduquer plutôt que sanctionner

Une gouvernance réussie ne peut être uniquement technologique ; elle doit être culturelle. Le Shadow AI prospère souvent sur l’ignorance des risques et non sur une volonté de nuire. Pour y remédier, le DSI doit instaurer un véritable contrat social avec les utilisateurs : la charte de bonne conduite.

L’enjeu est de transformer chaque collaborateur en un maillon de la chaîne de cybersécurité. Cela passe par une compréhension fine du concept de « Human-in-the-loop ». Forrester avertit d’ailleurs que « le plus grand risque de l’IA générative n’est pas ce qu’elle fait, mais ce que les humains font avec elle sans supervision. » La charte doit donc insister sur la responsabilité éditoriale : l’IA propose, mais l’humain dispose et vérifie.

La transparence devient ici une valeur cardinale. En encourageant les employés à déclarer leurs usages plutôt qu’à les cacher, la DSI peut identifier les cas d’usage à fort ROI. Cette approche pédagogique permet également de lutter contre les biais et les hallucinations, en rappelant que l’IA est un outil probabiliste et non une source de vérité absolue. C’est en accompagnant l’utilisateur dans son « AI Literacy » (sa culture de l’IA) que le DSI réduit naturellement le recours aux solutions de l’ombre.

L’architecture du « Safe Harbor »

Pour rendre la solution officielle plus attractive que le Shadow AI, le DSI doit bâtir un environnement qui surclasse les outils grand public. C’est ici qu’intervient le concept de Sandbox IA, ou « port sécurisé ». Techniquement, cette infrastructure repose sur le déploiement d’instances privées via des services comme Azure OpenAI ou AWS Bedrock, garantissant que les données saisies ne sortent jamais du périmètre de l’entreprise et ne servent jamais à l’entraînement de modèles tiers.

L’innovation majeure de ces environnements réside dans la couche de Data Guardrails. Contrairement à une interface publique, la sandbox d’entreprise intègre des filtres de Data Loss Prevention (DLP) qui interceptent et anonymisent les informations sensibles avant qu’elles n’atteignent le LLM. De plus, l’intégration du RAG (Retrieval-Augmented Generation) permet à l’IA d’interroger les documents internes de l’entreprise (bases de connaissances, archives, rapports) avec une précision que les outils publics ne peuvent égaler.

Enfin, cette approche offre au DSI une visibilité indispensable via le FinOps. En monitorant la consommation de « tokens » par département, la DSI peut non seulement contrôler les coûts, mais aussi prioriser les investissements sur les projets les plus créateurs de valeur.

Selon Gartner, « d’ici 2026, 75 % des organisations auront établi une stratégie de gouvernance de l’IA, contre moins de 5 % aujourd’hui. » La sandbox n’est pas seulement un outil technique, c’est le laboratoire où se prépare l’avenir de l’entreprise.

——————————————————————————————————————————–

——————————————————————————————————————————–

The post Comment piloter le Shadow AI appeared first on Silicon.fr.

« Hello world ne compile pas ».

Avec un tel intitulé, le premier ticket ouvert dans le dépôt GitHub de CCC n’est pas passé inaperçu. Il faut dire que le projet lui-même a particulièrement attiré l’attention. Et pour cause : Claude est parvenu à créer son propre compilateur C.

Un ingénieur d’Anthropic est à l’origine de la démarche. Il lui aura fallu deux semaines, environ 2000 sessions Claude Code et près de 20 000 $ de coûts d’API pour la mener à bien, explique-t-il. Au final, il y a environ 100 000 lignes de code Rust… et la capacité à compiler Linux 6.9 sur x86-64, i686, AArch64 et RISC-V 64, sans dépendances.

GCC comme oracle et un lieur qui fait encore défaut

La compilation se fait sans erreurs (ce qui est notable), mais l’assemblage et l’édition de liens – composantes cruciales d’un compilateur – ne sont pas stables. Par ailleurs, les niveaux d’optimisation doivent encore être implémentés.

Si la supervision humaine fut minimale (pas de consignes de débogage, notamment, ni de fourniture de feed-back sur la qualité du code), Claude n’a pas été tout à fait autonome. Outre les tests qui ont permis de le garder sur les rails au fil du projet, un algorithme de synchronisation a évité que des agents tentent de résoudre le même problème en même temps.

CCC (Claude’s C Compiler) a effectivement exploité des instances parallèles de Claude Opus 4.6. L’approche a favorisé la spécialisation des tâches : un agent pour fusionner le code en double, un deuxième pour écrire la doc, un troisième pour analyser la conception du projet point de vue d’un développeur Rust, etc.

L’algo en question pose des verrous sur des tâches en écrivant des fichiers texte dans un dossier current_tasks/. Les conflits de merge sont fréquents, mais Claude sait les gérer, nous affirme-t-on. À chaque session, tous les agents ont leur propre conteneur Docker avec une copie locale du repo Git.

Ce système a fonctionné pour compiler de « petits » projets open source (SQLite, QuickJS, mbedTLS, libpng…), chaque agent pouvant se concentrer sur l’un d’entre eux. Avec Linux, ils ont fini par converger sur la même tâche. Et donc à se « marcher sur les pieds ». Le compilateur GCC a alors été utilisé comme oracle. Le tout sans orchestrateur : chaque agent décide de ses actions, en documentant ses éventuels échecs.

Une compilation moins efficace…

Claude Opus 4.5 fut le premier LLM d’Anthropic capable de produire un compilateur réussissant les suites de tests référentes, fait remarquer l’ingénieur. L’apport de Claude Opus 4.6 est le passage à l’échelle, sur un projet de l’ampleur du noyau Linux.

Le code généré n’est cependant pas très efficace, reconnaît-il. Même avec toutes les optimisations possibles, on n’atteint pas ce que GCC délivre sans.
Un comparatif tiers le confirme. Son auteur a analysé, d’une part, la compilation de Linux 6.9 (x86-64). De l’autre, celle de SQLite 3.46.0. Son setup : deux VM Debian sous Proxmox, chacune sur son nœud physique (6 vCPU, 16 Go de RAM, 100 Go NVMe).

Avec GCC 14.2.0, la compilation de SQLite prend 64,6 s. Il en faut 87 avec CCC.
Sans optimisation, GCC produit un binaire de 1,55 Mo. Contre 4,27 Mo pour CCC. Le premier consomme au maximum 272 Mo de RAM ; le second, 1616 Mo.

… et surtout une exécution beaucoup plus lente

L’écart est beaucoup plus net sur le temps d’exécution : 10,3 secondes avec GCC sans optimisation… contre 2 h 6 min avec CCC. Cette lenteur n’est pas uniforme. Elle est moindre sur des requêtes somples comme la suppression de tables ou l’ajout de lignes. Elle est au contraire bien plus importante avec les opérations qui impliquent des boucles imbriquées.

Cette différence s’explique entre autres par une mauvaise allocation des registres CPU (CCC éparpille les variables sur la pile). La taille du code généré joue aussi : elle favorise les défauts de cache d’instructions (le CPU ne peut pas tout conserver en L1/L2). De surcroît, la production de pointeurs corrompus et l’absence de génération de tables de symboles rend le profilage et le débogage impossibles.

Pour ce qui est du kernel, CCC compile tous les fichiers sources sans erreur, mais échoue au niveau du lieur. Il génère, en particulier, des entrées de relocalisation incorrectes pour les jump labels.

Illustration générée par IA

The post Claude crée son propre compilateur C : oui, mais… appeared first on Silicon.fr.