En juin 2026, le NCSC, l'agence britannique de cybersécurité, a publié une approche du développement assisté par IA qui mérite l'attention des DSI. Elle tient en une phrase : le risque n'est pas d'utiliser l'IA, c'est de ne pas appliquer les bons garde-fous quand l'enjeu est élevé. Un spectre plutôt qu'une règle unique Le NCSC décrit un continuum. À gauche, le développement manuel, avec une IA limitée à l'autocomplétion. Au centre, des approches hybrides : l'IA écrit des fonctions, l'humain garde l'architecture, les tests pilotent le développement. À droite, le vibe coding complet, où l'IA reçoit des consignes de haut niveau et décide de l'architecture, du code et des tests. Aucune position n'est interdite. Tout dépend de ce qu'on construit. Où placer chaque projet Vers la droite, les prototypes, les démonstrations, les outils internes. Vers la gauche, l'authentification et les autorisations, le traitement de données sensibles, la gestion des identifiants, les infrastructures critiques. La supervision suit les conséquences d'une défaillance. Pour les systèmes sensibles, le NCSC attend une revue du code produit par l'IA, une compréhension complète de ce code, une évaluation des vulnérabilités et une vérification fonctionnelle. Et une architecture qui limite l'impact d'une éventuelle exploitation. Le test, variable d'ajustement du spectre La grille transforme un débat idéologique en décision d'ingénierie. Pour chaque application, un niveau de conséquence. Pour chaque niveau, un degré de supervision. Et ce degré se traduit en exigences de test très concrètes : tests fonctionnels automatisés, tests de sécurité, non-régression, fréquence d'exécution. Un outil interne peut vivre avec des tests légers. Un module de paiement, non. Par où commencer Peu d'organisations ont fait ce classement. Le code généré arrive souvent avec le même niveau de contrôle partout, de l'outil interne au module critique. Un premier pas raisonnable : classer ses applications en trois niveaux de conséquence, puis associer à chacun des exigences minimales de revue et de test, écrites et connues des équipes. Ça ne demande ni outil ni budget. Juste une décision.
