La nouvelle habitude en matière de sécurité consiste à vérifier avant de générer
Les assistants de codage basés sur l’IA ne remplacent pas les développeurs humains dans les tâches de sécurité. Ils déplacent simplement une grande partie de ce travail vers une autre étape : du moment de l’écriture du code vers celui de la spécification, de la révision, des tests et de la validation. Ce changement est d’ordre pratique, et non philosophique. Une équipe peut avoir l’impression d’avancer plus vite parce qu’un agent produit un correctif fonctionnel en quelques minutes, mais cette même équipe peut se retrouver moins en sécurité si personne n’a défini ce que le correctif ne doit pas faire, quelles données il ne doit pas toucher et quelles hypothèses de sécurité doivent être vérifiées avant que la pull request ne soit fusionnée.
Deux signaux récents font de ce sujet une question d’actualité pour les équipes de développement logiciel. Le Conseil de la politique technologique de l’ACM a averti en avril que le « vibe coding » peut accélérer le développement tout en faisant l’impasse sur les pratiques qui rendent les logiciels sûrs, fiables et faciles à maintenir. Un article de SOUPS publié en 2026 sur les assistants de codage basés sur l’IA et la sensibilisation à la sécurité parvient à une conclusion complémentaire : les assistants ont tendance à réorganiser la réflexion sur la sécurité plutôt qu’à l’éliminer. Les développeurs écrivent peut-être moins lors de la première ébauche, mais ils doivent vérifier davantage le comportement final. La sécurité devient réactive à moins que l’équipe ne la rende délibérément visible plus tôt.
Pour Paye ta com, la leçon est simple : un processus de livraison assisté par l’IA ne devrait pas demander aux humains de simplement valider le code généré à la fin. Il devrait demander aux humains de définir le modèle de risque dès le début, de superviser l’agent pendant l’exécution et d’exiger des preuves avant le déploiement. L’intervention humaine n’est pas une simple formalité. C’est l’humain qui décide du modèle de menace, de la limite de confiance, du compromis acceptable et de la norme de vérification.
Pourquoi la génération masque les décisions de sécurité
Un développeur humain effectue généralement de nombreux petits choix de sécurité au fur et à mesure qu’il code. Il décide si un terminal nécessite une authentification, si un champ peut être consigné, si une bibliothèque est suffisamment aboutie, si les données saisies par l’utilisateur doivent être normalisées et si un message d’erreur en révèle trop. Ces choix ne sont souvent pas consignés par écrit, car les ingénieurs expérimentés les intègrent comme des réflexes professionnels. Le risque lié à l’assistance par l’IA est que ces réflexes disparaissent de la vue. L’assistant reçoit une tâche telle que « ajouter une réinitialisation de mot de passe » ou « créer une exportation d’administrateur », puis complète l’architecture, les dépendances, la gestion des erreurs et les tests à partir de modèles qu’il a observés ailleurs.
Cette extension cachée est utile, mais c’est aussi là que commence la dette de sécurité. Un modèle peut produire un code plausible qui fonctionne lors d’un test en scénario idéal tout en choisissant silencieusement une durée de vie de jeton insuffisante, une requête de base de données trop large, une ligne de journalisation trop détaillée ou un contrôle d’autorisation manquant. Le problème n’est pas que le modèle soit malveillant. Le problème est que la tâche n’était pas suffisamment précisée et que la réponse générée semble suffisamment complète pour décourager un examen plus approfondi.
C’est pourquoi la discussion sur la sécurité doit commencer avant même que l’instruction ne soit envoyée. Une bonne instruction destinée à un agent de codage ne doit pas se contenter de décrire la fonctionnalité. Elle doit nommer les ressources, les attaquants, les autorisations, les modes de défaillance et les contraintes. Au lieu de « crée un point de terminaison pour le téléchargement de fichiers », l’humain devrait préciser : les téléchargements ne sont pas fiables, il ne faut pas se fier aux noms de fichiers, le type de contenu ne constitue pas une garantie, les objets stockés doivent être privés par défaut, une analyse anti-malware est requise avant la publication, et le point de terminaison doit faire l’objet de tests pour détecter les fichiers trop volumineux et les tentatives de traversée de chemin. L’agent peut toujours apporter son aide. Mais désormais, il intervient dans un cadre défini par un ingénieur.
La sécurité réactive est une sécurité coûteuse
Lorsque l’assistance par IA repousse la sécurité au stade de la révision, les équipes découvrent souvent les problèmes trop tard. Une détection tardive coûte cher, car le correctif généré a déjà créé une situation : la fonctionnalité semble exister, la démo fonctionne, le ticket est sur le point d’être clôturé, et le réviseur ressent une pression pour accepter la forme de la solution. À ce stade, soulever une objection de sécurité peut donner l’impression de ralentir l’équipe, même lorsque cette objection concerne le travail qui protège les utilisateurs et l’entreprise.
La sécurité réactive pose également un problème d’attention. Les réviseurs doivent inspecter des différences plus importantes qu’auparavant, parfois dans des fichiers que l’agent n’était pas censé modifier. Ils doivent distinguer les codes standard générés inoffensifs des modifications subtiles apportées à l’autorisation, à la sérialisation, à la configuration des dépendances, aux scripts de compilation ou à l’observabilité. Plus l’assistant produit de code, plus il devient facile pour une ligne dangereuse de se cacher dans un océan de code apparemment correct. Une révision humaine qui se contente de demander « est-ce que ça compile ? » ne suffit plus.
L’antidote consiste à intégrer les preuves de sécurité dans la définition de « terminé ». Si un agent IA intervient sur l’authentification, la logique de paiement, les données personnelles, l’infrastructure, les manifestes de dépendances ou les tâches en arrière-plan, la pull request doit contenir des notes explicites sur la propriété de sécurité préservée. Quels utilisateurs sont autorisés à appeler ce chemin ? Quelles données sont lues ou écrites ? Quels tests vérifient aussi bien les échecs que les réussites ? Quels journaux ont été vérifiés pour détecter la présence de secrets ? Quelle modification de dépendance ou de configuration a été justifiée ? Ces notes ne relèvent pas de la bureaucratie. Elles permettent aux humains de retrouver une visibilité lorsque les machines génèrent du code plus rapidement qu’ils ne peuvent le lire ligne par ligne.
Dirigez l’agent à l’aide d’un modèle de menace, pas d’un vœu pieux
La méthode pratique consiste à associer à chaque tâche de codage d’IA non triviale un petit modèle de menace. Il n’est pas nécessaire que ce soit un long document. Il peut s’agir d’une courte liste de contrôle jointe à la ticket ou à l’invite. L’humain nomme l’actif, le point d’entrée, l’acteur, l’autorisation attendue, le cas d’abus et le test qui permettrait de le détecter. Cela transforme l’assistant, qui passe d’un devineur autonome à un exécutant mandaté.
Par exemple, un ticket indiquant « ajouter un bouton d’exportation » invite l’agent à se concentrer sur l’interface utilisateur et une requête de données. Un ticket plus sûr stipule : « ajouter une exportation au format CSV réservée aux administrateurs de l’organisation ; n’inclure en aucun cas les hachages de mots de passe, les jetons, les notes internes ou les comptes supprimés ; appliquer l’autorisation sur le serveur, et pas seulement dans l’interface utilisateur ; transmettre la réponse en continu sans charger tous les enregistrements en mémoire ; ajouter des tests prouvant qu’un membre sans droits d’administrateur se voit refuser l’accès ; ajouter un événement de journalisation sans données personnelles ». La deuxième version n’est pas plus longue parce que les humains se méfient de l’outil. Elle est plus longue parce que les humains comprennent le système.
Ce style améliore également la collaboration entre les équipes produit, ingénierie et sécurité. L’équipe produit peut définir la valeur pour l’utilisateur. L’équipe ingénierie peut définir les limites de la mise en œuvre. L’équipe sécurité peut définir les cas d’abus. L’IA peut alors rédiger le code, les tests, les notes de migration et la documentation dans un cadre commun. Tout le monde gagne en rapidité car il y a moins d’hypothèses cachées.
Utilisez l’IA pour contrôler l’IA, mais gardez un responsable humain
Il n’y a rien de mal à utiliser un deuxième modèle, un analyseur statique, un scanner de dépendances ou un vérificateur de politiques pour réviser le code généré. En fait, les équipes devraient le faire. La révision assistée par l’IA permet de repérer les tests manquants, les autorisations suspectes, les fonctions non sécurisées, les dépendances obsolètes ou la gestion incohérente des erreurs. Elle peut résumer un diff volumineux et indiquer à un humain les fichiers qu’il convient d’inspecter en priorité. Elle peut également générer des cas de test adversaires que le premier agent n’a pas écrits.
Mais la révision automatisée ne doit pas se transformer en absolution automatisée. Un modèle qui déclare « ça a l’air sûr » n’assume pas la responsabilité métier. Un scanner qui ne signale rien n’a pas prouvé l’absence de failles. Une suite de tests « verte » ne prouve que les propriétés qui ont effectivement été testées. Le réviseur humain reste responsable de décider si les preuves sont suffisantes au regard du risque. Cela signifie que les réviseurs doivent avoir le pouvoir de bloquer, de restreindre ou d’annuler le travail généré par l’IA, même lorsque la démonstration semble impressionnante.
Une règle utile consiste à séparer la rédaction de la validation. Laissons l’agent rédiger le code et proposer des tests. Laissons les outils générer des suggestions de révision. Mais exigeons qu’un humain désigné valide les modifications qui affectent les limites de confiance, les secrets, l’identité, les paiements, la conformité ou les opérations de production. Cet humain désigné ne doit pas être choisi au hasard. Il doit comprendre le domaine concerné ou avoir accès à quelqu’un qui le comprend. L’intervention humaine ne fonctionne que lorsque la personne dispose du contexte, du temps et de l’autorisation de dire non.
Rendez le flux de travail visible
De nombreux risques liés à l’IA proviennent d’un flux de travail invisible. Un développeur accepte une suggestion importante, un agent modifie plusieurs fichiers, une dépendance apparaît dans un manifeste, un test est réécrit pour qu’il passe, et le diff final ressemble à un travail humain ordinaire. Quelques semaines plus tard, personne ne se souvient quelles décisions ont été générées, lesquelles ont été revues et lesquelles ont simplement été supposées. Il s’agit là d’un échec de gouvernance, non pas parce que les équipes ont besoin de mise en scène, mais parce qu’elles ont besoin de traçabilité.
Les équipes peuvent améliorer cela grâce à des pratiques simples. Marquez les pull requests qui contiennent une part importante de code généré par l’IA. Demandez aux agents de produire un résumé des modifications et un résumé des risques. Conservez les invites ou les fiches de mission pour les travaux sensibles. Exigez des relecteurs qu’ils précisent ce qu’ils ont vérifié. Enregistrez quand un outil a exécuté des commandes, modifié des dépendances ou migré des données. Ces pratiques n’ont pas pour but de stigmatiser l’utilisation de l’IA. Elles la normalisent tout en clarifiant les responsabilités.
La visibilité facilite également la maintenance future. Le développeur qui déboguera cette fonctionnalité dans six mois devra savoir pourquoi une condition de sécurité a été mise en place, pourquoi une dépendance a été choisie et pourquoi un test couvre un cas de refus inhabituel. Le code généré par l’IA qui ne peut être expliqué par des humains devient une dette opérationnelle. Le code généré par l’IA qui est documenté, testé et dont la responsabilité est clairement attribuée peut devenir un logiciel ordinaire et maintenable.
Ce que les équipes devraient changer cette semaine
Tout d’abord, modifiez les modèles de tickets pour les travaux assistés par l’IA. Ajoutez des champs pour les hypothèses de sécurité, les données traitées, les autorisations requises et les tests attendus. Le modèle doit être suffisamment court pour que les utilisateurs s’en servent, mais suffisamment concret pour qu’un agent reçoive plus qu’un simple vœu pieux. Deuxièmement, modifiez les invites pour les fonctionnalités à risque. Demandez à l’assistant d’identifier les fichiers sensibles en matière de sécurité, de proposer des tests avant toute modification et d’expliquer tout changement de dépendance ou de configuration.
Troisièmement, modifiez les listes de contrôle de révision. Les réviseurs doivent vérifier si l’autorisation est appliquée côté serveur, si des secrets ou des données personnelles sont enregistrés, si les tests générés démontrent des cas d’échec, si les dépendances sont justifiées et si le code reste compréhensible pour un mainteneur humain. Quatrièmement, modifiez les règles de fusion pour les domaines à haut risque. Toute modification générée par l’IA concernant l’authentification, la facturation, l’infrastructure ou l’exportation de données doit être soumise à un réviseur responsable de ce domaine.
Cinquièmement, utilisez l’IA de manière défensive. Demandez à un assistant distinct de tester le correctif sous angle d’attaque : « Comment un utilisateur pourrait-il contourner l’autorisation à cet endroit ? » « Quelle entrée pourrait provoquer le plantage de cet analyseur syntaxique ? » « Quelle ligne de journalisation pourrait entraîner une fuite de données personnelles ? » « Quel test échouerait si la vérification des autorisations était supprimée ? » Ces questions transforment le modèle en un amplificateur de révision tout en laissant à l’humain le contrôle de la décision finale.
Conclusion : un code plus rapide nécessite une prise de décision plus précoce
Le potentiel du développement assisté par l’IA est bien réel. Il permet de réduire le temps passé devant une page blanche, de générer des structures de base, de traduire l’intention en exemples fonctionnels et d’aider les équipes à explorer des alternatives. Mais le coût en matière de sécurité est également bien réel lorsque la génération remplace les petits jugements humains qui intervenaient auparavant lors de la mise en œuvre. Si les équipes attendent la dernière pull request pour réfléchir à la sécurité, elles gaspilleront leurs gains en fatigue de révision, en retouches et en incidents évitables.
La meilleure voie n’est pas de rejeter les assistants de codage. C’est de les maîtriser. Les humains doivent définir le risque, les limites, les preuves et les critères d’acceptation avant que la machine n’écrive trop de code. Les agents peuvent alors rédiger, tester, résumer et remettre en question. Ce sont les humains qui décident si le résultat est suffisamment sûr pour être déployé. Dans une culture d’ingénierie assistée par l’IA, la révision de sécurité commence avant l’écriture du code, car la responsabilité commence avant l’écriture du code.
