Les outils de codage par AI tels que Cursor, Claude Code, GitHub Copilot et Windsurf peuvent écrire, refactoriser et déboguer le code d’un site web rapidement, mais ils introduisent également de nouveaux risques : code non sécurisé qui semble correct, secrets divulgués, modifications non examinées sur les serveurs en direct et licences peu claires. Un court ensemble de règles de gouvernance, convenu avant le premier prompt, maintient la vitesse tout en protégeant le site, les données et la marque.
Que sont ces outils et en quoi diffèrent-ils ?
Cursor est un éditeur de code construit sur VS Code avec un assistant AI qui peut lire le projet et modifier plusieurs fichiers à la fois. Claude Code est l’agent en ligne de commande d’Anthropic qui travaille dans un dépôt, exécute des commandes et propose ou applique des changements. GitHub Copilot a commencé comme une autocomplétion et inclut désormais des modes de chat et d’agent dans les éditeurs courants. Plusieurs autres suivent le même modèle.
Le changement qui compte pour la gouvernance est l’autonomie. L’autocomplétion suggère une ligne et un développeur l’accepte. Les agents peuvent ouvrir des fichiers, installer des paquets, exécuter des commandes de base de données et pousser des changements. Plus un outil peut faire de choses sans qu’une personne n’approuve chaque étape, plus vos règles doivent préciser ce qu’il peut toucher.
Qu’est-ce qui peut mal tourner sur un site web professionnel ?
La plupart des incidents tombent dans une poignée de catégories. Aucun n’est hypothétique ; chacun est un risque logiciel normal qui devient plus fréquent lorsque le code est produit plus rapidement qu’il n’est examiné.
- Failles de sécurité : manque de validation des entrées, SQL construit à partir de chaînes, contrôles d’authentification faibles ou téléchargements de fichiers permissifs qui passent un coup d’œil rapide.
- Exposition de secrets : clés API collées dans des prompts, validées dans le dépôt ou imprimées dans des journaux que l’outil lit.
- Commandes destructives : un agent exécutant une réinitialisation de base de données, un git push forcé ou une suppression massive de fichiers dans le mauvais environnement.
- Risque de dépendance : l’outil ajoute un paquet qui est obsolète, abandonné ou, dans de rares cas, une imitation d’un vrai paquet.
- Régressions cachées : une refactorisation qui corrige une page et casse silencieusement le paiement, les formulaires ou les balises de suivi ailleurs.
- Questions de licence et de propriété intellectuelle sur le code généré et sur le code client envoyé à un modèle tiers.
Quelles limites les équipes doivent-elles attendre ?
Les outils de codage par AI sont forts pour le code standard, l’explication de code inconnu, l’écriture de tests, la conversion de designs en composants et la correction de bugs clairement décrits. Ils sont plus faibles lorsque l’exigence est vague, lorsque la base de code a des conventions non documentées, ou lorsque la réponse correcte dépend du contexte commercial que le modèle ne peut pas voir.
Ils font aussi des erreurs avec assurance. Un outil peut prétendre qu’un correctif fonctionne sans l’exécuter, inventer une fonction qui n’existe pas dans votre version d’une bibliothèque, ou produire du code qui passe les tests parce qu’il a modifié les tests. Traitez chaque sortie comme une pull request d’un développeur junior rapide qui ne se fatigue jamais et ne pose jamais de questions.
Quelles règles de gouvernance devez-vous définir en premier ?
Commencez par des règles qui sont peu coûteuses à suivre et coûteuses à ignorer. Vous pouvez les affiner plus tard, mais celles-ci doivent être écrites avant que quiconque ne connecte un agent à un dépôt client.
- Pas d’accès à la production : les agents travaillent sur des copies locales ou de staging ; le déploiement passe par le pipeline normal.
- Examen humain pour chaque changement : rien n’est fusionné sans qu’un examinateur nommé ne lise le diff.
- Les secrets restent à l’extérieur : les clés vivent dans des variables d’environnement ou un gestionnaire de secrets, jamais dans des prompts, du code ou des journaux de chat.
- Paramètres d’autorisation : restreignez les commandes qu’un agent peut exécuter sans demander, et bloquez les commandes destructives par défaut.
- Outils et comptes approuvés : plans d’affaires avec des conditions de rétention de données claires, pas de comptes personnels gratuits.
- Politique de dépendance : les nouveaux paquets ont besoin d’une raison, d’une vérification du statut de maintenance et de l’approbation d’un examinateur.
- Journalisation : conservez la session ou le résumé de ce que l’outil a changé pour toute version destinée au client.
Un fichier d’instructions de projet aide
De nombreux outils lisent un fichier de projet avec des instructions permanentes, comme CLAUDE.md pour Claude Code ou des fichiers de règles dans Cursor. Utilisez-le pour enregistrer les conventions, les actions interdites, les commandes de test et les zones fragiles connues. Il ne remplace pas l’examen, mais il réduit les erreurs répétées et documente les décisions pour le prochain développeur.
Comment garder la qualité mesurable ?
La vitesse est facile à ressentir et difficile à vérifier. Suivez quelques indicateurs afin que l’équipe puisse voir si l’assistance par AI améliore le travail ou ne fait que l’accélérer.
- Couverture de tests automatisés sur les flux critiques tels que le paiement, les formulaires et la connexion.
- Core Web Vitals après chaque version : LCP inférieur à 2,5 secondes, INP inférieur à 200 ms, CLS inférieur à 0,1.
- Nombre de bugs signalés dans la semaine suivant la version, par rapport au trimestre précédent.
- Résultats d’analyse de sécurité provenant d’outils tels que GitHub code scanning, Snyk ou un scanner de sécurité WordPress.
- Temps d’examen par pull request, pour repérer quand les examinateurs valident aveuglément de grands diffs générés par l’AI.
À qui appartiennent le code et les données ?
Deux questions surgissent dans chaque conversation avec le client. Premièrement, qu’arrive-t-il au code envoyé au modèle ? Les plans d’affaires et d’entreprise des principaux fournisseurs indiquent généralement que le code client n’est pas utilisé pour l’entraînement, mais les conditions diffèrent et changent, alors lisez l’accord actuel et enregistrez le plan que vous utilisez. Deuxièmement, à qui appartient le résultat ? Les contrats doivent indiquer clairement que le code livré appartient au client, quel que soit l’outil qui a aidé à l’écrire.
Comment Alien Road applique les outils de codage par AI
Dans un engagement typique, nous commençons par la découverte de la pile du client, de l’hébergement, du processus de déploiement et de toute limite de conformité concernant l’envoi de code à des services externes. Cela détermine quels outils sont autorisés et sur quels dépôts.
La configuration comprend un environnement de staging, un fichier d’instructions de projet, des autorisations d’agent restreintes et un audit des secrets. Les développeurs utilisent les outils pour l’échafaudage, les refactorisations et les tests, et chaque changement passe par un examen et des contrôles automatisés avant le déploiement. La mesure couvre la fréquence de publication, les bugs après publication et les Core Web Vitals, et le rapport mensuel au client liste ce qui a été construit avec l’assistance par AI, ce qui a été examiné et les problèmes trouvés.
Par où commencer cette semaine
Rédigez une politique de codage par AI d’une page avec les sept règles ci-dessus, puis exécutez une analyse des secrets sur le dépôt principal de votre site web. Si l’analyse trouve des clés, faites-les pivoter en premier. Après cela, configurez une copie de staging et laissez un développeur y essayer un agent sur une petite tâche bien définie avec un examinateur assigné. Vous apprendrez plus d’une semaine supervisée que de n’importe quelle démo de fournisseur.
Continuez à lire : Conception et développement web · Conception web