Les outils de codage IA pour sites web, tels que Cursor et Claude Code, sont des assistants qui lisent les fichiers d’un projet, proposent des modifications de code et exécutent des commandes sur instruction d’un développeur. En agence, ils accélèrent le travail répétitif de construction, de refactorisation et de débogage, tandis que les humains restent responsables de l’architecture, des décisions de conception, de la revue de sécurité et de la validation finale avant que quoi que ce soit n’atteigne le site en ligne d’un client.
Qu’est-ce que Cursor et Claude Code ?
Cursor est un éditeur de code construit sur la base open-source de Visual Studio Code, créé par la société Anysphere. Il ajoute des fonctionnalités d’IA directement dans l’éditeur : complétions en ligne, un panneau de chat qui peut voir le projet ouvert et un mode agent qui modifie plusieurs fichiers à la fois. Les développeurs peuvent choisir entre des modèles de différents fournisseurs.
Claude Code est l’outil de ligne de commande d’Anthropic. Il s’exécute dans un terminal, lit le dépôt et peut modifier des fichiers, exécuter des tests et utiliser git lorsque le développeur l’autorise. Il est également disponible dans les éditeurs et les applications de bureau. Sa force réside dans le traitement de tâches en plusieurs étapes, comme le traçage d’un bug à travers un thème et deux plugins, tout en demandant la permission avant d’effectuer des actions risquées.
Les deux outils ne sont aussi bons que le contexte qu’ils reçoivent. Un projet avec une structure claire, des conventions écrites et des tests fonctionnels donne des résultats bien meilleurs qu’un enchevêtrement d’extraits copiés.
Quelles parties de la construction d’un site web accélèrent-ils ?
Les gains se concentrent sur le travail bien défini mais fastidieux. Un humain décide toujours de ce qui doit se passer ; l’outil gère une grande partie de la saisie et de la recherche.
- Échafaudage (Scaffolding) : création de modèles de blocs, de types de publication personnalisés ou de fichiers de composants qui suivent un modèle existant.
- Refactorisation : renommer des fonctions dans les fichiers, diviser une grande feuille de style en fichiers de composants, supprimer le code mort.
- Débogage : lire les journaux d’erreurs, trouver où une valeur tourne mal et suggérer une correction à tester.
- Passages d’accessibilité : ajout d’étiquettes manquantes, d’attributs alt et de styles de focus, puis vérification du contraste.
- Scripts de données : importations ponctuelles, cartes de redirection d’URL et nettoyages de contenu pour les migrations.
- Documentation : rédaction de notes README pour les décisions afin que le prochain développeur les comprenne.
Où les humains prennent-ils encore les décisions ?
Plusieurs domaines restent fermement entre les mains des personnes, quoi que suggère l’outil. L’architecture de l’information, le système de conception visuelle et les choix de marque proviennent de la stratégie et de la recherche, pas de la génération de code. Il en va de même pour toute décision concernant les données qu’un site collecte et leur destination.
La sécurité est l’exemple le plus clair. Un assistant peut écrire un gestionnaire de formulaire qui fonctionne mais qui oublie les vérifications de nonce, le nettoyage des entrées ou les vérifications de capacité. Chaque changement qui touche aux entrées utilisateur, aux paiements ou à l’authentification reçoit une revue humaine ligne par ligne, aussi propre soit-il.
Comment Alien Road utilise Cursor et Claude Code dans les projets clients
La découverte passe en premier et se déroule sans outils d’IA : nous convenons des objectifs, des types de pages, des intégrations et des sources de contenu avec le client. Le résultat est un brief écrit et un fichier de conventions de projet qui décrit la structure des dossiers, les règles de nommage et les éléments qui ne doivent jamais changer. Ce fichier devient plus tard le contexte pour les outils de codage.
La configuration s’exécute dans un environnement de développement local, généralement Docker, jamais directement sur un serveur en ligne. Les développeurs utilisent Claude Code ou Cursor pour des tâches telles que la génération d’un ensemble de modèles de blocs à partir de conceptions approuvées ou l’écriture du script d’importation qui déplace les anciens articles de blog vers une nouvelle structure. Par exemple, une migration peut impliquer des centaines d’articles où l’outil écrit le script, mais un développeur l’exécute d’abord en mode test (dry-run) et vérifie un échantillon manuellement.
Chaque changement passe par git. Les commits sont petits, les messages expliquent la raison et rien n’est fusionné sans qu’un humain ne vérifie le diff. La mesure couvre le temps de construction par modèle de page, les défauts trouvés lors des tests et les Core Web Vitals après le lancement. Les clients reçoivent un court rapport qui liste ce qui a été automatisé, ce qui a été révisé et ce qui a été testé.
Comment garder le code écrit par l’IA fiable ?
Le risque principal est un code qui semble correct et passe un coup d’œil rapide, mais échoue sur des cas limites. Les modèles ont également tendance à ajouter de nouvelles fonctions d’assistance au lieu de réutiliser celles existantes, ce qui alourdit lentement une base de code.
Notez les règles
Les deux outils lisent les fichiers d’instructions du projet. Claude Code utilise un fichier CLAUDE.md ; Cursor prend en charge les fichiers de règles. Enregistrez les décisions qui vous ont coûté du temps à apprendre, comme pourquoi un fichier de modèle ne doit pas être supprimé ou quelle fonction gère les chemins. L’outil évite ainsi de répéter les anciennes erreurs.
Testez ce qui compte
Exécutez des vérifications de linting et de syntaxe après chaque modification, comme php -l pour les fichiers PHP. Gardez une courte liste d’URL à charger après chaque changement et vérifiez les erreurs. Pour le travail de mise en page, vérifiez les largeurs comme 390, 768 et 1440 pixels avant de considérer une tâche comme terminée.
Limitez les permissions
Autorisez librement l’accès en lecture et les modifications de fichiers, mais exigez une confirmation pour les commandes qui suppriment des données, poussent du code ou touchent aux bases de données. Ne collez jamais de clés API de production dans un prompt ou un fichier que l’outil peut commiter.
Que devrait demander un client à une agence utilisant ces outils ?
- Chaque changement assisté par l’IA est-il révisé par un développeur nommé avant le déploiement ?
- Où le développement est-il effectué et les données du client quittent-elles cet environnement ?
- Quelles parties du code sont couvertes par des tests ou des vérifications manuelles ?
- À qui appartiennent le code et les fichiers d’instructions à la fin du projet ?
- Comment les secrets tels que les clés API sont-ils tenus à l’écart des prompts et des dépôts ?
Des réponses claires à ces questions montrent que l’agence traite les outils comme des instruments, et non comme un remplacement du savoir-faire. Des réponses vagues sont un signe d’avertissement.
Quelles erreurs les équipes commettent-elles lorsqu’elles adoptent ces outils pour la première fois ?
L’erreur la plus courante est d’en demander trop dans une seule requête. Un prompt comme “reconstruis l’en-tête” invite l’outil à réécrire des fichiers qu’il n’a pas besoin de toucher. Des tâches plus petites et spécifiques, comme déplacer le bouton de recherche après le sélecteur de langue à des largeurs supérieures à 1080 pixels, produisent des changements qu’un réviseur peut vérifier en quelques minutes.
La deuxième erreur est de sauter la copie locale. Exécuter un agent contre un serveur de staging semble plus rapide, mais une mauvaise commande peut écraser des téléchargements ou des paramètres. Un environnement local jetable avec une exportation de base de données fraîche élimine ce risque et permet aux développeurs d’essayer deux approches côte à côte avant d’en choisir une.
Par où commencer cette semaine
Si vous gérez votre propre site, commencez par une tâche en lecture seule. Installez l’un des outils sur une copie locale du projet et demandez-lui d’expliquer comment le thème charge ses styles ou où vit une fonctionnalité spécifique. Comparez sa réponse avec ce que vous savez. Ensuite, écrivez un fichier de conventions d’une page pour le projet. Même si vous ne laissez jamais un assistant modifier une ligne, ce fichier fera gagner des heures au prochain développeur.
Continuez à lire : Conception et développement web · Conception web