Pour les agences WordPress modernes, la clé d’un avantage concurrentiel ne réside plus dans la qualité du code. Les agences axées sur la croissance automatisent les tâches répétitives, réduisent leurs coûts opérationnels et leurs délais de mise sur le marché, et proposent à leurs clients des services davantage personnalisés.
L’intégration d’outils d’IA dans les processus de production est cruciale pour les agences qui cherchent à automatiser leurs flux de travail. Dans ce contexte, le Vibe Coding — ce nouveau paradigme de développement piloté par l’IA — gagne chaque jour davantage en popularité.
Le Vibe Coding n’est toutefois pas une méthode facile pour écrire du code. S’il est vrai que vous n’avez pas besoin d’années d’expérience pour tirer parti de l’approche Vibe Coding, une solide compréhension de la programmation et des langages que vous utilisez est indispensable. Et ce n’est pas tout. Outre les compétences traditionnelles en codage, il est désormais essentiel de développer un éventail plus large de compétences. Savoir utiliser les outils basés sur l’IA les plus performants en fait sans aucun doute partie.
Êtes-vous prêt à mettre en œuvre le Vibe Coding dans les flux de travail WordPress de votre agence ? Poursuivez votre lecture.
Les workflows WordPress avec le Vibe Coding
Si vous ne l’avez pas encore adoptée, la méthode Vibe Coding est une méthodologie de développement axée sur l’efficacité et l’optimisation des ressources. Avec Vibe Coding, vous cessez d’écrire physiquement des lignes de code et passez à un niveau d’abstraction supérieur : celui de l’intention. En tant que développeur, vous définissez l’architecture, la logique ainsi que les exigences techniques et métier d’un projet web, en déléguant le codage proprement dit à l’agent d’IA.
L’adoption de l’approche « Vibe » pour l’automatisation des processus apporte des avantages significatifs : réduction des délais de mise sur le marché, démocratisation de l’automatisation, ainsi que flexibilité et adaptabilité des processus. Ces avantages se traduisent par une efficacité et une évolutivité accrues. Grâce à l’automatisation des flux de travail et à l’introduction de Vibe Coding, les agences WordPress peuvent évoluer plus facilement, car l’intégration de nouveaux clients n’entraîne pas d’augmentation de la charge de travail ni des frais généraux.
Avant de vous réjouir, vous devez toutefois garder à l’esprit que le « Vibe Coding » n’est pas une panacée qui produit comme par magie un code bien structuré, facile à maintenir et fonctionnant toujours comme prévu. L’adoption de ce nouveau paradigme nécessite de comprendre le fonctionnement des agents IA et doit s’inscrire dans une architecture respectant les principes et les bonnes pratiques qui en font une approche fiable pour une agence WordPress.
Dans les sections suivantes, nous allons nous pencher sur la création d’un flux de travail automatisé pour l’intégration d’un nouveau projet WordPress, en suivant une approche pratique basée sur un cas d’utilisation concret : nous verrons comment cloner un modèle de site WordPress préconfiguré hébergé sur Kinsta à l’aide de GitHub Copilot et de l’API Kinsta.
Nous espérons que cet article vous aidera à comprendre les avantages de l’automatisation et comment mettre en œuvre efficacement le « Vibe Coding » dans le flux de travail de développement de votre agence.
Votre boîte à outils d’automatisation
Tout d’abord, vous aurez besoin d’un modèle de site hébergé sur Kinsta. Pour cet exemple, nous avons créé un nouveau site et installé les thèmes Astra, GeneratePress et Neve. Nous avons également installé Yoast SEO, Starter Templates et d’autres extensions complémentaires pour le thème Astra.
Pour créer un clone de votre site, vous devrez accéder à votre environnement d’hébergement Kinsta via l’API Kinsta. Vous aurez besoin d’une clé API Kinsta, de l’identifiant de votre entreprise et de l’identifiant de l’environnement que vous souhaitez cloner.
Vous pouvez obtenir l’identifiant de votre entreprise à partir de l’URL de votre tableau de bord MyKinsta (le paramètre idCompany) et dans la section Informations sur le site de MyKinsta, en accédant à Sites > nom-du-site > Info. Dans cette même section, vous trouverez également l’identifiant de votre environnement.
Enfin, vous aurez besoin d’un IDE pour travailler. Parmi les nombreuses options disponibles, on trouve des environnements de développement largement utilisés tels que Visual Studio Code ou Cursor, ou encore des environnements de développement axés sur l’IA comme Lovable. Vous pouvez également utiliser une plateforme de prototypage en ligne telle que Google AI Studio, idéale pour tester des invites dans un environnement de test isolé avant de passer au développement proprement dit.
Pour cet article, nous avons utilisé Google AI Studio pour la création d’invites et GitHub Copilot dans Visual Studio Code pour développer l’application. Voici pourquoi cette configuration fonctionne si bien :
- Adoption généralisée : GitHub Copilot est extrêmement populaire et fait déjà partie intégrante de la pile technologique de nombreuses agences WordPress. L’utiliser pour un projet d’automatisation des flux de travail signifie que votre équipe n’aura pas à passer du temps à se familiariser avec de nouveaux outils de développement.
- Accès direct au système de fichiers : Copilot a accès au système de fichiers de votre projet. Cela lui permet de créer directement les fichiers nécessaires, y compris les éléments de configuration, et d’écrire du code en fonction de vos requêtes.
- Instructions de l’agent : vous pouvez définir des règles globales, au niveau du projet, à l’aide d’un fichier de configuration «
.github/copilot-instructions.md». L’agent suivra strictement ces instructions système, garantissant ainsi que chaque fichier respecte les normes de votre projet.
En gardant ces fonctionnalités à l’esprit, découvrons comment fonctionne GitHub Copilot.
L’expérience de codage avec GitHub Copilot : modes, fenêtre de contexte et instructions de l’agent
Comprendre le fonctionnement de GitHub Copilot est essentiel pour exploiter pleinement son potentiel. Dans cette section, vous vous familiariserez avec les concepts de base de Copilot.
Modes de Copilot
Il existe trois modes distincts que vous pouvez utiliser pour interagir avec GitHub Copilot, chacun déterminant le type de conversation que vous entretenez avec le chatbot.
Plan : en mode Plan, Copilot génère un plan structuré, décomposé en tâches, qui est ensuite transmis au mode Agent pour exécution (voir ci-dessous pour plus de détails). Cela permet à l’agent de rester pleinement concentré sur les objectifs globaux du projet et de suivre efficacement les progrès réalisés.
En mode « Plan », Copilot fournit une feuille de route détaillée, accompagnée des étapes de mise en œuvre et de vérification. Après avoir examiné la proposition, vous pouvez soumettre vos commentaires afin d’apporter les ajustements nécessaires. Lorsque le plan correspond à vos besoins, vous pouvez passer à la mise en œuvre.
Le mode Plan propose un ensemble complet d’outils accessibles sous Configurer les outils, directement dans la fenêtre de discussion.
Agent : en mode Agent, Copilot analyse votre demande, consulte un modèle d’IA pour déterminer comment résoudre la tâche, puis se met au travail. Une fois la première itération terminée, Copilot effectue une vérification pour détecter d’éventuelles erreurs et détermine les corrections nécessaires, qu’il s’agisse de modifications du code, de commandes de terminal ou d’appels d’outils.
Par défaut, tous les outils disponibles sont présélectionnés en mode Agent.
Pour plus d’informations sur les agents, veuillez vous reporter à la documentation officielle de VS Code.
Ask : le mode Ask permet de poser des questions via la fenêtre de discussion. Ce mode est recommandé pour obtenir de l’aide et poser des questions générales sur le codage.
Ces trois modes de GitHub Copilot suivent une séquence chronologique et logique précise au sein du cycle de vie du développement d’une application.
Au cours de la phase initiale d’architecture du projet, le mode « Plan » vous aide à définir les étapes logiques de votre feuille de route : identification des fichiers à créer, des dépendances à installer et de l’architecture sous-jacente.
Lors de la phase de codage proprement dite, le mode « Agent » prend en charge la création des fichiers et la génération du code. À ce stade, l’agent devient autonome. Votre rôle évolue vers celui de superviseur : vous fournissez les retours nécessaires pour résoudre les blocages ou affiner certaines parties spécifiques de la base de code.
Le mode « Ask » s’avère à nouveau utile pendant la phase de débogage. Dans ce mode, Copilot vous aide à dissiper vos doutes, gère les exceptions et documente votre code.
Fenêtre de contexte
Le contexte correspond à tout ce que le modèle peut voir lorsqu’il traite une réponse. Il comprend notamment l’historique de votre conversation, les fichiers présents dans votre espace de travail local ou distant, les instructions système et personnalisées, les résultats des outils, ainsi que toutes les références que vous ajoutez explicitement à la conversation.
La qualité des réponses dépend du contexte ; il est donc essentiel de fournir au modèle des informations pertinentes et appropriées.
Le modèle ne dispose pas d’une mémoire illimitée. La fenêtre de contexte correspond à la quantité maximale de données — mesurée en tokens (fragments de mots ou de code) — qu’un LLM peut traiter et « garder en mémoire » à un moment donné au cours d’un cycle unique de requête et de réponse. Dans VS Code, vous pouvez voir combien de tokens sont disponibles dans votre fenêtre de contexte en cliquant sur l’icône située dans le coin inférieur droit, à côté de la fenêtre de discussion.
La fenêtre de contexte représente la mémoire à court terme du modèle. Si elle est saturée, l’agent risque de renvoyer des données incorrectes ou incohérentes. Un risque encore plus grand est la pollution du contexte, qui survient lorsque la fenêtre de contexte est remplie d’informations non pertinentes. Dans les deux cas — que ce soit par saturation ou par pollution du contexte —, Copilot peut générer des bogues, produire des résultats erronés ou générer du code non optimisé.
Pour éviter de passer des heures à essayer d’obtenir un code propre et exempt de bogues, il est essentiel de respecter une hygiène stricte dans la discussion. Vous pouvez y parvenir en fermant les onglets dont vous n’avez pas strictement besoin, en utilisant des références de fichiers explicites pour enrichir le contexte, en compactant l’historique de votre chat avec /compact, ou simplement en ouvrant une toute nouvelle fenêtre de discussion pour repartir de zéro avec un contexte vierge.
Instructions destinées à l’agent
Les instructions destinées à l’agent définissent les règles de comportement qui influencent directement la manière dont l’agent génère du code et gère diverses tâches de développement. Cela vous garantit d’obtenir un code conforme aux normes de votre entreprise, utilisant exclusivement des bibliothèques autorisées, et préservant la sécurité totale des données stratégiques telles que les clés API.
Au lieu d’inclure manuellement ces directives dans chaque invite, vous pouvez spécifier vos instructions personnalisées dans un fichier Markdown afin de garantir que les réponses soient toujours conformes aux exigences de votre entreprise et de votre projet. Si vous disposez de plusieurs fichiers d’instructions, VS Code les combine automatiquement et les ajoute au contexte de discussion.
En fournissant des instructions précises, Copilot ne confondra pas les noms de paramètres dans les requêtes API et ne commettra pas d’erreurs lors du traitement des réponses provenant d’un service externe.
Mais ne vous inquiétez pas trop si cela vous semble compliqué. GitHub Copilot peut en effet générer un fichier d’instructions pour vous. Il vous suffit de suivre les étapes décrites dans la documentation officielle.
Maintenant que nous avons abordé les bases, vous apprendrez dans la section suivante à développer une application d’automatisation de flux de travail WordPress basée sur l’API Kinsta à l’aide de GitHub Copilot dans VS Code. Il est temps de retrousser vos manches et de vous mettre au travail.
Programmer un workflow d’automatisation WordPress concret
Tout comme pour le codage traditionnel, le « vibe coding » d’un projet avancé tel que l’automatisation d’un workflow WordPress implique une séquence de phases logiques tout au long du cycle de vie du développement logiciel.
C’est pourquoi nous avons décomposé le processus de « vibe-coding » d’un projet d’automatisation de flux de travail WordPress en une série d’étapes logiques. Plongeons-nous dans chaque phase et découvrons ce qui change avec l’approche du « vibe-coding » :
Définition des règles
Au cours de cette phase, vous devez définir les directives générales qui établissent les limites dans lesquelles l’agent évoluera. Cela implique la création de fichiers de contexte qui définissent la pile technologique, les consignes de sécurité et les modèles de journalisation structurés.
Après avoir créé un nouveau dossier de projet dans VS Code, votre première étape consiste à ouvrir la discussion Copilot et à entamer une conversation avec l’agent afin de définir le plan directeur du projet. Au cours de cette phase initiale, vous travaillerez principalement en mode « Ask » (Demander) pour déterminer le langage le plus approprié à votre projet et élaborer votre ensemble d’instructions destinées à l’agent.
Choisissez le langage du projet
Si vous n’avez pas encore choisi votre pile technologique, votre première question doit viser à déterminer le langage le plus adapté à votre projet. Pour notre workflow d’automatisation, nous avons demandé à Copilot de dresser la liste des avantages et des inconvénients de Node.js par rapport à Python :
Copilot a répondu en présentant une analyse détaillée des avantages et des inconvénients des deux langages, et a finalement recommandé Node.js :
Instructions pour la conception d’agents
Nous avons ensuite demandé à Copilot comment concevoir correctement des instructions personnalisées pour l’agent afin de minimiser les « hallucinations » et d’éviter toute perte de contexte :
Copilot a recommandé de diviser nos instructions pour l’agent en plusieurs fichiers. Cela permettrait d’éviter la pollution du contexte.
Après avoir bien compris la recommandation de Copilot, nous sommes passés à la planification de l’architecture de nos instructions d’agent.
Nous avons basculé Copilot du mode Ask au mode Plan, en lui demandant de définir la structure de fichiers pour notre système d’instructions modulaire avec des fichiers distincts .md :
Copilot a commencé à définir les étapes, en fournissant un raisonnement clair tout en posant une série de questions afin d’adapter les règles à la configuration de notre projet.
Nous avons transmis les liens suivants à Copilot :
https://api-docs.kinsta.com/api-reference/wordpress-sites/get-list-of-company-sites
https://api-docs.kinsta.com/api-reference/wordpress-sites/get-site-by-id
https://api-docs.kinsta.com/api-reference/wordpress-sites/clone-existing-siteCopilot a décomposé les phases d’exécution, expliqué la justification technique de ses choix et demandé si nous étions prêts à appliquer les modifications.
L’approbation du plan proposé fait automatiquement passer Copilot du mode « Plan » au mode « Agent ». L’agent IA travaille alors directement sur votre système de fichiers local pour créer vos fichiers d’instructions d’agent.
L’image ci-dessous présente un aperçu du fichier « copilot-instructions.md » :
Développement itératif
Il s’agit de la phase de création du code. L’agent IA génère les fichiers de projet et les scripts, tandis que le développeur joue le rôle d’architecte et de directeur du processus. En d’autres termes, au cours de cette phase, vous demanderez à Copilot de créer la structure et le code de l’application, vous fournirez les informations et les retours nécessaires, vous évaluerez les options disponibles et vous prendrez des décisions stratégiques.
La prochaine étape de notre projet d’automatisation du flux de travail WordPress consiste à initialiser le projet Node.js et à définir la structure des fichiers. Nous sommes revenus en mode Plan et avons demandé à Copilot de planifier les étapes suivantes :
Copilot a produit un plan détaillé, accompagné d’informations supplémentaires sur les fichiers concernés, les vérifications à effectuer et les décisions à prendre. Après avoir soigneusement examiné la réponse, nous avons lancé la mise en œuvre.
Si cela vous semble fastidieux, ne vous inquiétez pas outre mesure. Vous demanderez à Copilot d’effectuer toutes les opérations nécessaires à votre place.
Lors de la génération des fichiers, Copilot vous demandera probablement votre avis sur certains points nécessitant des éclaircissements ou votre autorisation avant de poursuivre certaines opérations. Examinez ces demandes et procédez en conséquence.
Une fois une opération terminée, Copilot vous indiquera la marche à suivre :
La conversation se poursuit sous forme de questions-réponses jusqu’à ce que Copilot ait créé l’ensemble des fichiers et du code pour votre application. Dans l’invite suivante, nous avons demandé à Copilot, en mode Plan, de générer un modèle pour le fichier « .env » et de mettre en place les contrôles de sécurité appropriés (fail-fast).
L’image suivante montre le fichier « .env.example » généré par Copilot :
Nous avons ensuite demandé la génération d’un fichier index.js encapsulant l’intégralité de la logique de l’application. Pour une application plus avancée, il aurait été préférable de diviser le script en plusieurs fichiers ; pour cette application, nous avons préféré conserver toute la logique dans un seul script.
Il est temps d’exécuter notre script. Avant de lancer le clonage du site, nous avons créé un fichier .env en nous basant sur .env.example et avons remplacé les espaces réservés par les valeurs réelles de KINSTA_API_KEY, KINSTA_COMPANY_ID et SOURCE_ENVIRONMENT_ID.
Une fois que vous avez terminé la configuration du script et des variables d’environnement, ouvrez le terminal de VS Code et saisissez « npm start ».
Si tout fonctionne comme prévu, vous verrez apparaître un nouveau site portant un nom générique dans MyKinsta. Si l’invite affiche une erreur, il vous suffit de copier le message d’erreur depuis le terminal et de le coller dans la discussion Copilot afin que l’agent puisse l’évaluer, en identifier la cause et proposer des solutions adaptées. Il se peut qu’il vous demande des précisions supplémentaires.
À ce stade, vous souhaiterez peut-être apporter des améliorations ou ajouter de nouvelles fonctionnalités à votre application. Dans notre cas de figure, le nom générique du site généré par le script n’était pas idéal. Nous sommes donc passés à la deuxième itération.
Affiner votre application
Après avoir franchi notre première étape — le clonage automatique d’un site WordPress hébergé sur Kinsta —, nous avons demandé à Copilot d’ajouter une fonctionnalité permettant aux utilisateurs de spécifier un nom de site personnalisé lors de l’exécution.
Le point de terminaison /sites/clone de l’API Kinsta nécessite 3 paramètres : company, source_env_id et display_name. Alors que les deux premiers réglages sont définis de manière fixe en tant que variables d’environnement dans notre fichier .env, le paramètre display_name est généré automatiquement par le script.
Fournir aux utilisateurs de l’application une variable d’environnement de secours leur aurait offert une plus grande flexibilité, tout en leur permettant de transmettre un paramètre supplémentaire directement via la commande npm run.
Nous avons transmis cette demande à Copilot. L’agent a mis en œuvre les modifications requises en modifiant à la fois index.js et .env, puis a fourni la réponse suivante :
Enfin, nous avons testé notre application en conditions réelles dans différents contextes, en suivant les instructions de Copilot :
- Nous avons exécuté
npm runsans aucun paramètre. - Nous avons défini une valeur par défaut pour la constante
SITE_NAMEdans le fichier.env, puis nous avons relancénpm run. - Nous avons ajouté manuellement le paramètre
SITE_NAME=your-site-nameà la commandenpm run. - Nous avons exécuté le script en utilisant à la fois les syntaxes
npm start -- --site-name your-site-nameetnpm start -- --site-name=your-site-name.
Animés par ce cycle d’amélioration continue, nous avons également intégré une fonctionnalité permettant de normaliser les saisies manuelles en un nom d’affichage lisible, tout en continuant à accepter de manière transparente les valeurs de type « slug » telles que my-awesome-wordpress-website.
Par conséquent, les deux commandes suivantes sont prises en charge :
npm start -- --site-name="My Awesome WordPress Website"
npm start -- --site-name=my-awesome-wordpress-websiteSi vous êtes arrivé jusqu’ici, félicitations : vous venez de créer votre toute première application d’automatisation de flux de travail en « vibe-coding ». Vérifiez maintenant les extensions, les thèmes et le rendu côté client. Si vous pensez à des fonctionnalités supplémentaires pour améliorer votre script, continuez simplement à le développer en suivant l’approche itérative décrite ci-dessus.
Contrôles de sécurité « fail-fast »
Pour une application critique utilisant des données sensibles, telles que vos clés API, il est essentiel que le script effectue des contrôles rigoureux à des moments clés de l’exécution et, en cas d’échec, renvoie des messages clairs sur le type d’erreur et interrompe immédiatement l’exécution (voir l’invite ci-dessus).
GitHub Copilot a mis en œuvre la « fail-fast » à trois niveaux critiques :
Validation de l’environnement : à ce niveau, le script vérifie que les variables d’environnement existent avant d’effectuer tout appel d’API ou d’exécuter toute tâche. L’image suivante montre l’explication de Copilot concernant ce contrôle dans la discussion :
Bien entendu, votre code peut différer de ce qui est illustré dans l’image, mais c’est l’approche qui importe ici.
Validation de la réponse API : dès le début du clonage, le script vérifie immédiatement l’existence d’un identifiant d’opération. Si le script reçoit un identifiant non valide, il interrompt immédiatement son exécution, évitant ainsi de l’interroger pendant une demi-heure. Vous trouverez ci-dessous l’explication fournie par Copilot :
Propagation gracieuse des erreurs : toute erreur survenant à n’importe quel maillon de la chaîne (validation, API, interrogation) est remontée en surface, enregistrée dans les journaux et entraîne l’arrêt propre de l’exécution du script.
L’approche « fail-fast » présente plusieurs avantages, notamment :
- Aucun appel d’API inutile
- Des messages d’erreur clairs
- Vous savez immédiatement ce qui ne va pas
Pour les agences WordPress susceptibles de devoir faire évoluer une application de ce type et de cloner des dizaines de sites de façon groupée, cette approche permet de détecter immédiatement les échecs de script à n’importe quel niveau, empêchant ainsi qu’ils ne se répercutent en cascade sur plusieurs opérations.
Toutefois, si votre application est destinée à évoluer, vous aurez intérêt à mettre en place un système de tests unitaires.
Tests unitaires avec Jest
Au cours de la phase de développement, Copilot a exécuté de manière autonome plusieurs tests locaux, notamment :
npm run check— des tests exécutés après chaque modification, afin de détecter les erreurs de syntaxe.npm start— des tests exécutés plusieurs fois pour observer les réponses de l’API et identifier les bogues.npm start 2>&1 | head -30— des tests effectués pour capturer et lire en temps réel les sorties de journaux structurées.
Bien que ces tests aient aidé Copilot à détecter un certain nombre de bogues, ils restent assez basiques et ne fonctionnent vraiment que pour une application simple. De plus, ils présentent un inconvénient majeur : chaque fois que vous exécutez npm start, vous déclenchez un clonage du site. Cela peut rapidement vous faire atteindre la limite de capacité de votre plan, comme vous pouvez le voir sur l’image ci-dessous :
De plus, ces tests ne peuvent pas être exécutés dans un pipeline CI/CD sans exposer vos identifiants.
Pour faire évoluer véritablement votre application, il est essentiel d’adopter un framework de tests unitaires robuste tel que Jest.
Au lieu d’envoyer à chaque fois des requêtes réelles aux serveurs de Kinsta, Jest vous permet d’intercepter et de simuler les réponses API (mocking). Cela vous permet de tester le comportement de votre logiciel en toute isolation.
De plus, comme les appels API sont simulés, Jest vous permet d’exécuter l’intégralité de votre suite de tests au sein de pipelines d’automatisation tels que GitHub Actions sans avoir à utiliser vos identifiants de production.
Pour mettre en place Jest dans votre projet d’automatisation, vous pouvez demander à Copilot des instructions étape par étape ou le laisser se charger du travail à votre place.
Une fois Jest configuré, vous pouvez exécuter tous vos tests en une seule fois à l’aide de la commande npm test. Vous pouvez également cibler un fichier spécifique ou exécuter des tests en mode Watch :
Il convient également de noter que Copilot intègre des commandes de chat qui vous aident à réaliser des tests unitaires avec Jest :
/testsgénère un fichier de test pour le fichier actuellement ouvert. Lorsque vous saisissez «/tests» dans la discussion, Copilot génère des tests Jest pour les fonctions qu’il trouve dans ce fichier.@workspace /testseffectue la même opération que la commande précédente, mais en tenant compte du contexte complet du projet.
Lorsque vous discutez avec Copilot en mode Ask, vous recevrez des recommandations et des conseils pour vous guider dans vos tests unitaires :
Ouvrez une nouvelle conversation pour ce test et assurez-vous qu’elle est configurée sur « Agent mode ». Ensuite, collez la commande fournie précédemment par Copilot directement dans la conversation :
@workspace /tests for pollUntilComplete and KinstaClient using fetch mocksAppuyez sur Entrée, et vous verrez le raisonnement de Copilot ainsi que les opérations étape par étape s’afficher dans la conversation. Il vous demandera de confirmer l’exécution de la commande à chaque fois qu’il lancera un test, jusqu’à ce que toutes les erreurs soient corrigées.
Documentation et déploiement
Un code bien documenté est essentiel à la maintenabilité du code source. C’est pourquoi nous avons demandé à Copilot de générer un fichier README.md à la racine du projet. Nous lui avons demandé de décrire l’application, de préciser les exigences, d’expliquer comment configurer le fichier .env, de présenter les différentes façons de démarrer l’application et de montrer comment exécuter les tests.
Nous avons lancé une nouvelle conversation en mode Ask, ajouté les fichiers index.js et package.json au contexte (voir le raccourci #filename de Copilot), puis transmis à Copilot la consigne suivante :
Copilot a fourni un aperçu d’un fichier README.md. Nous l’avons soigneusement examiné, puis sommes passés en mode Agent pour créer le fichier.
L’étape suivante consistait à documenter le code lui-même. Le fichier index.js étant ouvert, nous avons sélectionné l’intégralité du code pour l’ajouter au contexte de discussion, puis avons envoyé la demande suivante en mode Ask :
Copilot a mis à jour le fichier index.js en y ajoutant une documentation intégrée sans modifier le code.
Une fois encore, comme nous étions en mode Ask, Copilot n’avait pas l’autorisation de modifier nos fichiers. Nous sommes donc passés en mode Agent et avons demandé à Copilot de mettre à jour le fichier index.js avec les modifications proposées.
La dernière étape consiste à déployer l’application. Deux options principales s’offrent à vous :
- Conserver l’application sur une machine locale. Cette solution est idéale lorsque vous décidez de déclencher la création du site manuellement, par exemple juste après la signature d’un contrat par un nouveau client.
- Intégrer le script dans un pipeline CI/CD en poussant le code vers un dépôt GitHub. La création du site peut alors être déclenchée manuellement ou automatiquement en réponse à un événement spécifique. Cette solution est parfaite si vous travaillez avec des workflows plus structurés et évolutifs.
Si vous optez pour la configuration sur un ordinateur local ou un serveur utilitaire, vous êtes prêt. Si vous choisissez la voie plus structurée du pipeline CI/CD, vous pouvez demander à Copilot de vous aider à rédiger la commande parfaite.
Notre application est terminée. Désormais, l’intégration d’un nouveau projet WordPress se résume simplement à exécuter la commande suivante :
npm start -- --site-name="My Awesome WordPress Website"Vibe Coding et l’automatisation : l’avenir des agences WordPress avant-gardistes
Le Vibe Coding n’est pas simplement une approche simpliste de l’écriture de code. Il s’agit plutôt d’une nouvelle méthodologie de développement qui redéfinit complètement le rôle du développeur : celui-ci n’est plus un programmeur au sens traditionnel du terme, mais le directeur d’un processus itératif englobant l’exploration, la planification, le codage, l’amélioration, les tests, le débogage, la documentation et le déploiement.
Si tel est l’avenir du développement logiciel et de l’évolutivité des agences, il est alors essentiel de s’associer à une plateforme d’hébergement avant-gardiste pour rester compétitif à l’ère de l’IA. En tirant parti de la puissance de l’API Kinsta et en orchestrant des agents IA selon des règles claires, des tests rigoureux et une documentation solide, votre agence cessera de courir sans cesse après les urgences et commencera à travailler de manière plus efficace, plus prévisible et plus évolutive.
Prêt à faire évoluer vos workflows WordPress et à réduire considérablement vos délais de développement ? Découvrez nos formules ou contactez notre équipe commerciale et commencez dès aujourd’hui à mettre en place votre pipeline d’automatisation.
Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.
