Modèles de Prompts IA en Français

Guide professionnel de prompts IA optimisés pour le développement WordPress, l’administration VPS/Debian et les workflows Git. Compatible avec Claude.ai et ChatGPT.

—

Table des Matières

• Développement WordPress
• Administration VPS & Debian
• Sécurité Système
• Workflows Git
• Développement Assisté par IA
• WordOps & Optimisation
• Debugging & Résolution de Problèmes
• Documentation Technique

—

1. Développement WordPress

1.1 Création de Plugin WordPress

Contexte : Je développe un plugin WordPress professionnel.

Objectif : Créer [FONCTIONNALITÉ SPÉCIFIQUE]

Contraintes techniques :
Compatibilité : WordPress 6.4+, PHP 8.1+
Standards : WordPress Coding Standards, PSR-4 autoloading
Sécurité : Nonces, sanitization, capability checks
Performance : Lazy loading, caching optimal

Structure souhaitée :
Architecture MVC ou modulaire
Hooks et filtres documentés
Fichiers de traduction (i18n) prêts
Tests unitaires (optionnel)

Livrables attendus :
Code source complet avec commentaires
Structure de fichiers recommandée
Dépendances Composer si nécessaire
Exemples d'utilisation

Fonctionnalité demandée : [DÉCRIRE EN DÉTAIL]

Exemple d’utilisation :

Fonctionnalité demandée : Un système de cache avancé pour les requêtes API externes
avec invalidation automatique basée sur des règles personnalisables et dashboard
d'administration pour monitorer les performances.

—

1.2 Optimisation de Requêtes WordPress

Je rencontre un problème de performance sur mon site WordPress.

Contexte technique :
Environnement : [VPS Debian 12, Nginx, PHP 8.2, MariaDB 10.11]
Trafic : [X visiteurs/jour]
Problème observé : [Temps de chargement, requêtes lentes, etc.]

Code actuel :
[COLLER LE CODE ICI]

Analyse demandée :
Identifier les requêtes inefficaces (N+1, etc.)
Proposer des optimisations concrètes
Recommander des stratégies de cache appropriées
Suggérer des index MySQL si pertinent

Objectif : Réduire le temps d'exécution de [X]% ou sous [Y] secondes.

Exemple d’utilisation :

Environnement : VPS Debian 12, Nginx, PHP 8.2, MariaDB 10.11
Trafic : 5000 visiteurs/jour
Problème observé : Page d'archive prend 3-4 secondes à charger

Code actuel :
$posts = getposts(array(
    'postsperpage' => -1,
    'metakey' => 'featured',
    'metavalue' => '1'
));
foreach($posts as $post) {
    $author = getuserby('id', $post->postauthor);
    $categories = getthecategory($post->ID);
    // ... traitement
}

—

1.3 Création de Bloc Gutenberg

Je souhaite créer un bloc Gutenberg personnalisé.

Type de bloc : [Static / Dynamic / Editable]

Fonctionnalité :
[DÉCRIRE LA FONCTIONNALITÉ]

Attributs nécessaires :
[Attribut 1] : type, default, validation
[Attribut 2] : type, default, validation

Interface souhaitée :
Sidebar controls : [liste des contrôles]
Toolbar options : [liste des options]
Inspector controls : [paramètres avancés]

Stack technique préférée :
[ ] JavaScript vanilla + WordPress API
[ ] React + @wordpress/components
[ ] TypeScript (optionnel)

Livrables :
Code du bloc (block.json, edit.js, save.js)
Styles (editor.css, style.css)
Build configuration (webpack/esbuild)
Documentation d'utilisation

Exemple d’utilisation :

Type de bloc : Dynamic

Fonctionnalité : Affichage de témoignages clients avec carrousel,
filtrage par catégorie et notation étoiles

Attributs nécessaires :
numberOfPosts : number, default 6
category : string, default 'all'
showRating : boolean, default true
autoplay : boolean, default false

Stack technique préférée : React + @wordpress/components

—

2. Administration VPS & Debian

2.1 Configuration Serveur Sécurisé

Je dois configurer un nouveau VPS Debian pour héberger des sites WordPress.

Spécifications serveur :
OS : Debian [VERSION]
RAM : [X] GB
CPU : [X] cores
Nombre de sites prévus : [X]
Trafic estimé : [X] visiteurs/jour

Stack souhaitée :
[ ] Nginx / [ ] Apache
PHP [VERSION]
MariaDB / MySQL [VERSION]
[ ] WordOps / [ ] Configuration manuelle

Priorités :
Sécurité maximale (fail2ban, firewall, SSH hardening)
Performance optimale (cache, compression)
Monitoring (logs, alertes)
Backups automatisés

Fournir :
Script d'installation bash complet
Fichiers de configuration annotés
Checklist de sécurité post-installation
Commandes de vérification

Cas d'usage spécifique : [DÉCRIRE]

Exemple d’utilisation :

Spécifications serveur :
OS : Debian 12
RAM : 4 GB
CPU : 2 cores
Nombre de sites prévus : 3-5 sites WordPress
Trafic estimé : 10000 visiteurs/jour cumulés

Stack souhaitée : Nginx, PHP 8.2, MariaDB 10.11, WordOps

Cas d'usage spécifique : Hébergement de sites clients avec isolation complète
et possibilité de restauration rapide en cas de problème.

—

2.2 Troubleshooting Serveur

Mon serveur Debian rencontre un problème.

Symptômes :
[DÉCRIRE LES SYMPTÔMES OBSERVÉS]

Logs pertinents :

[COLLER LES LOGS ICI]

Contexte :
Dernières modifications : [changements récents]
Services affectés : [nginx, php-fpm, mysql, etc.]
Moment de l'incident : [date/heure]

Informations système :

[RÉSULTAT DE : top, free -h, df -h, netstat -tulpn]

Objectif : Diagnostiquer et résoudre le problème avec une solution durable.

Questions :
Quelle est la cause racine probable ?
Comment résoudre immédiatement ?
Comment prévenir la récurrence ?
Monitoring à mettre en place ?

Exemple d’utilisation :

Symptômes : Sites WordPress renvoient "502 Bad Gateway" de manière intermittente,
surtout pendant les pics de trafic (10h-12h).

Logs pertinents :
2025/12/18 10:45:23 [error] 1234#0: 567 connect() to unix:/run/php/php8.2-fpm.sock
failed (11: Resource temporarily unavailable) while connecting to upstream

Dernières modifications : Migration de PHP 8.1 vers 8.2 il y a 3 jours
Services affectés : php-fpm principalement

—

2.3 Automatisation avec Scripts Bash

Je souhaite automatiser une tâche d'administration système.

Tâche à automatiser :
[DÉCRIRE LA TÂCHE]

Fréquence : [quotidien, hebdomadaire, lors d'un événement]

Prérequis :
Exécution : [root, utilisateur spécifique]
Dépendances système : [outils nécessaires]
Notifications : [email, Slack, Discord, logs]

Comportement souhaité :
[Étape 1]
[Étape 2]
[Étape 3]

Gestion des erreurs :
Logging détaillé
Rollback si échec
Alertes en cas de problème

Livrables :
Script bash complet et commenté
Configuration cron si applicable
Documentation d'installation
Tests à effectuer

Contraintes : [sécurité, performance, compatibilité]

Exemple d’utilisation :

Tâche à automatiser : Backup complet de tous les sites WordPress (fichiers + bases
de données), compression, upload vers Backblaze B2, rotation (garder 7 jours de
backups quotidiens + 4 hebdomadaires).

Fréquence : Quotidien à 2h00 du matin

Prérequis :
Exécution : root
Dépendances : rclone, mysqldump, tar, gzip
Notifications : Email si échec

Contraintes : Minimiser l'impact sur les performances pendant l'exécution

—

3. Sécurité Système

3.1 Audit de Sécurité

Je souhaite effectuer un audit de sécurité complet de mon infrastructure.

Périmètre :
Serveur(s) : [liste des serveurs]
Applications : [WordPress, bases de données, services]
Niveau actuel : [débutant, intermédiaire, avancé]

Points à auditer :
Configuration SSH et accès système
Firewall et ports ouverts
Mises à jour et patches
Permissions fichiers et dossiers
Configuration PHP/MySQL
Sécurité WordPress (plugins, thèmes, core)
Certificats SSL/TLS
Logs et monitoring

Fournir :
Checklist complète d'audit
Commandes de vérification
Interprétation des résultats
Plan de remédiation priorisé
Scripts d'automatisation si possible

Format : [Rapport détaillé / Script automatisé]

Exemple d’utilisation :

Périmètre :
Serveurs : 1 VPS Debian 12 (production), 1 staging
Applications : 4 sites WordPress, MariaDB, Redis
Niveau actuel : Intermédiaire

Format : Script automatisé avec rapport détaillé en sortie

—

3.2 Durcissement Sécurité WordPress

Je veux renforcer la sécurité de mon/mes site(s) WordPress.

Configuration actuelle :
Version WordPress : [X.X]
Nombre de plugins : [X]
Rôles utilisateurs : [Admin, Editors, etc.]
Type de contenu : [blog, e-commerce, etc.]

Menaces identifiées ou craintes :
[brute force, injections SQL, XSS, etc.]

Niveau de sécurité souhaité :
[ ] Standard (protection de base)
[ ] Élevé (site sensible)
[ ] Maximum (données critiques)

Contraintes :
Budget plugins premium : [oui/non]
Modifications serveur autorisées : [oui/non]
Impact utilisateur acceptable : [minimal, modéré]

Fournir :
Configuration .htaccess / nginx optimale
Paramètres wp-config.php sécurisés
Recommandations plugins (gratuits prioritaires)
Headers de sécurité HTTP
Configuration SSL/HSTS
Checklist de maintenance sécurité

Focus particulier sur : [ASPECT SPÉCIFIQUE]

Exemple d’utilisation :

Configuration actuelle :
Version WordPress : 6.4.2
Nombre de plugins : 15
Rôles utilisateurs : 1 admin, 3 editors, 10 authors
Type de contenu : Magazine en ligne avec zone membres

Niveau de sécurité souhaité : Élevé

Contraintes :
Budget plugins premium : Non
Modifications serveur autorisées : Oui (VPS dédié)
Impact utilisateur acceptable : Minimal

Focus particulier sur : Protection des comptes utilisateurs et prévention
des attaques brute force

—

4. Workflows Git

4.1 Stratégie de Branching

Je configure un workflow Git pour mon projet WordPress.

Type de projet :
[ ] Plugin WordPress
[ ] Thème WordPress
[ ] Site complet
[ ] Projet multi-sites

Équipe :
Nombre de développeurs : [X]
Niveau Git : [débutant, intermédiaire, avancé]
Environnements : [dev, staging, production]

Besoins spécifiques :
Fréquence de déploiement : [quotidien, hebdo, mensuel]
Hotfixes : [critiques, rares]
Feature branches : [multiples simultanées, séquentielles]
Code review : [obligatoire, optionnel]

Fournir :
Stratégie de branching recommandée (Git Flow, GitHub Flow, etc.)
Conventions de nommage (branches, commits, tags)
Workflow complet illustré
Commandes Git courantes
Configuration .gitignore pour WordPress
Hooks Git utiles (pre-commit, pre-push)

Contraintes : [CI/CD, hooks de déploiement automatique]

Exemple d’utilisation :

Type de projet : Plugin WordPress commercial

Équipe :
Nombre de développeurs : 3
Niveau Git : Intermédiaire
Environnements : dev local, staging, production

Besoins spécifiques :
Fréquence de déploiement : Mensuel (releases majeures)
Hotfixes : Critiques (réponse rapide nécessaire)
Feature branches : 2-3 features en parallèle
Code review : Obligatoire avant merge

Contraintes : Déploiement automatique vers staging via GitHub Actions

—

4.2 Résolution de Conflit Git

Je rencontre un conflit Git que je ne parviens pas à résoudre.

Situation :
Branches impliquées : [branch1] et [branch2]
Opération tentée : [merge, rebase, cherry-pick]
Fichiers en conflit : [liste]

Contexte du conflit :
[EXPLIQUER L'HISTORIQUE DES MODIFICATIONS]

Conflit actuel :

[COLLER LA SORTIE DE git status ET LES MARQUEURS DE CONFLIT]

Objectif souhaité :
[DÉCRIRE LE RÉSULTAT ATTENDU]

Questions :
Quelle est l'approche recommandée (merge, rebase, autre) ?
Comment résoudre ce conflit spécifique ?
Comment éviter ce type de conflit à l'avenir ?
Commandes Git exactes à exécuter (étape par étape)

Note : Je préfère [préserver l'historique / historique linéaire]

Exemple d’utilisation :

Situation :
Branches impliquées : feature/new-api et develop
Opération tentée : git merge feature/new-api
Fichiers en conflit : includes/class-api-handler.php, readme.txt

Contexte : J'ai travaillé sur une nouvelle API pendant 2 semaines, pendant ce temps
l'équipe a refactorisé le système de routing dans develop.

Objectif : Intégrer mes changements d'API tout en conservant le nouveau système
de routing

Note : Je préfère un historique linéaire

—

4.3 Configuration Git Avancée

Je souhaite optimiser ma configuration Git pour le développement WordPress.

Environnement :
OS : [Linux, macOS, Windows]
IDE : [VS Code, PhpStorm, autre]
Terminal : [bash, zsh, fish]

Besoins :
Alias Git pour tâches courantes WordPress
Configuration globale optimale (.gitconfig)
Hooks Git personnalisés pour :
   - Vérification coding standards (PHPCS)
   - Tests automatiques
   - Prévention de commits sensibles (credentials)
Intégration avec [GitHub, GitLab, Bitbucket]
Signature GPG des commits (optionnel)

Cas d'usage spécifiques :
[DÉCRIRE VOS WORKFLOWS RÉPÉTITIFS]

Niveau : [débutant, intermédiaire, avancé]

Fournir configuration complète avec explications détaillées.

Exemple d’utilisation :

Environnement :
OS : Debian 12
IDE : VS Code
Terminal : zsh avec oh-my-zsh

Cas d'usage spécifiques :
Je travaille sur plusieurs plugins simultanément
Je dois souvent créer des branches de release avec numéros de version
Je veux automatiquement vérifier le coding standard avant chaque commit
Je collabore avec GitHub et utilise les Pull Requests

Niveau : Avancé

—

5. Développement Assisté par IA

5.1 Code Review par IA

Je souhaite que tu analyses ce code comme un senior developer.

Langage : [PHP, JavaScript, etc.]
Contexte : [WordPress plugin, thème, etc.]

Code à reviewer :

[LANGAGE]
[COLLER LE CODE ICI]

Critères d'évaluation :
Sécurité (injections, XSS, CSRF, etc.)
Performance (requêtes N+1, complexité algorithmique)
Maintenabilité (code smell, duplication, naming)
Standards WordPress (hooks, API, coding standards)
Tests (couverture, cas limites)
Documentation (PHPDoc, inline comments)

Format de réponse souhaité :
Note globale : X/10
Points forts : [liste]
Problèmes critiques : [liste avec priorité]
Suggestions d'amélioration : [code révisé]
Risques potentiels : [analyse]

Niveau d'exigence : [standard, élevé, perfectionniste]

Exemple d’utilisation :

Langage : PHP
Contexte : WordPress plugin - système de cache personnalisé

Niveau d'exigence : Élevé (code pour production)

Code à reviewer :

php
function getcacheddata($key) {
$cache = gettransient($key);
if (!$cache) {
$data = filegetcontents(‘https://api.example.com/data?key=’ . $key);
settransient($key, $data, 3600);
return $data;
}
return $cache;
}

—

5.2 Génération de Tests Unitaires

Génère des tests unitaires complets pour ce code WordPress.

Framework : [PHPUnit, Jest, autre]

Code source :

[LANGAGE]
[COLLER LE CODE À TESTER]

Couverture souhaitée :
[ ] Happy path (cas nominaux)
[ ] Edge cases (cas limites)
[ ] Error handling (gestion d'erreurs)
[ ] Mocks WordPress (functions, classes)
[ ] Integration tests (optionnel)

Contraintes WordPress :
Mocking requis pour : [getoption, wpdb, etc.]

Hooks à tester : [actions, filters]
Capabilities : [permissions utilisateurs]

Fournir :
Code des tests complets et annotés
Setup et teardown nécessaires
Mocks et fixtures
Commandes pour exécuter les tests
Coverage attendue : [X]%

Organisation : [un fichier / plusieurs fichiers par classe]

Exemple d’utilisation :

Framework : PHPUnit avec Brain Monkey pour WordPress

Couverture souhaitée : Tous cochés

Contraintes WordPress :
Mocking requis pour : getoption, updateoption, wpremoteget

Hooks à tester : monpluginbeforesave, monpluginaftersave

Capabilities : manageoptions

Coverage attendue : 90%+

Code source :

php
class APIManager {
public function fetchandstore($endpoint) {
$response = wpremoteget($endpoint);
if (iswperror($response)) {
return false;
}
$data = jsondecode(wpremoteretrievebody($response), true);
updateoption(‘apicache‘ . md5($endpoint), $data);
return $data;
}
}

—

5.3 Refactoring Assisté

Je souhaite refactoriser ce code legacy pour le moderniser.

Code actuel :

[LANGAGE]
[COLLER LE CODE LEGACY]

Problèmes identifiés :
[DÉCRIRE LES PROBLÈMES : performance, sécurité, lisibilité, etc.]

Objectifs de refactoring :
[Objectif 1 : ex. Passer de PHP 7.4 à 8.2]
[Objectif 2 : ex. Implémenter dependency injection]
[Objectif 3 : ex. Séparer concerns (MVC)]

Contraintes :
Rétrocompatibilité : [critique, souhaitable, non nécessaire]
Breaking changes acceptables : [oui/non]
Standards : [PSR-4, WordPress Coding Standards]
Architecture cible : [MVC, Clean Architecture, autre]

Livrables :
Code refactorisé complet
Migration guide (changements breaking)
Tests pour valider la non-régression
Documentation des nouvelles patterns utilisées
Comparatif avant/après (performance, complexité)

Focus : [performance, maintenabilité, sécurité, testabilité]

Exemple d’utilisation :

Problèmes identifiés :
Utilisation de variables globales partout
Logique métier mélangée avec la présentation
Aucune validation des entrées utilisateur
Requêtes SQL directes sans préparation

Objectifs de refactoring :
Éliminer toutes les variables globales
Séparer logique métier / présentation (MVC)
Implémenter validation et sanitization complètes
Utiliser $wpdb avec prepared statements

Contraintes :
Rétrocompatibilité : Non nécessaire (v2.0 avec breaking changes)
Standards : PSR-4 + WordPress Coding Standards
Architecture cible : MVC avec dependency injection

Focus : Sécurité et maintenabilité

Code actuel :

php
global $wpdb, $currentuser;
$id = $GET[‘id’];
$result = $wpdb->getresults(« SELECT FROM {$wpdb->prefix}custom WHERE id = $id »);
echo « 

 » . $result[0]->content . « 

« ;
if ($currentuser->ID == 1) {
echo « Delete« ;
}

—

5.4 Documentation Automatique

Génère une documentation complète pour ce code.

Type de documentation :
[ ] README.md pour GitHub
[ ] PHPDoc / JSDoc dans le code
[ ] Documentation utilisateur
[ ] Documentation développeur (API)
[ ] Guide de contribution

Code source :

[LANGAGE]
[COLLER LE CODE]

Audience cible :
[développeurs débutants, développeurs expérimentés, utilisateurs finaux]

Sections requises :
Description et objectif
Installation
Configuration
Utilisation avec exemples
API Reference
Hooks disponibles (WordPress)
FAQ / Troubleshooting
Contribution guidelines (si open-source)

Format :
Markdown avec syntaxe GitHub
Exemples de code exécutables
Screenshots si applicable : [oui/non]
Diagrammes : [oui/non - Mermaid]

Ton : [technique, pédagogique, conversationnel]

Exemple d’utilisation :

Type de documentation : README.md pour GitHub + PHPDoc dans le code

Audience cible : Développeurs WordPress intermédiaires

Sections requises : Toutes

Format :
Markdown avec syntaxe GitHub
Exemples exécutables
Screenshots : Non
Diagrammes : Oui (architecture avec Mermaid)

Ton : Pédagogique mais technique

Code source :
[Un plugin WordPress complet de gestion de cache]

—

6. WordOps & Optimisation

6.1 Configuration WordOps Personnalisée

Je configure WordOps pour un cas d'usage spécifique.

Objectif :
[DÉCRIRE LE CAS D'USAGE]

Spécifications :
Sites à héberger : [nombre et types]
Cache strategy : [Redis, FastCGI, autre]
SSL : [Let's Encrypt, custom]
CDN : [Cloudflare, autre, aucun]

Besoins particuliers :
[ ] Multi-sites WordPress
[ ] WooCommerce haute performance
[ ] Staging automatisé
[ ] Backups automatiques
[ ] Monitoring intégré

Configuration serveur actuelle :

[RÉSULTAT DE : wo info]

Demandes :
Configuration WordOps optimale (commandes wo)
Modifications post-installation recommandées
Configuration Nginx personnalisée si besoin
Stratégie de cache adaptée
Benchmarks attendus

Contraintes : [budget, ressources serveur, SLA]

Exemple d’utilisation :

Objectif : Héberger 3 sites WooCommerce avec trafic variable (5k-15k visiteurs/jour)

Spécifications :
Sites : 3 WooCommerce + 1 site vitrine
Cache strategy : Redis + FastCGI
SSL : Let's Encrypt avec wildcard
CDN : Cloudflare

Besoins particuliers :
WooCommerce haute performance (checkout rapide crucial)
Staging automatisé pour chaque site
Backups quotidiens vers B2

Configuration serveur actuelle :
Debian 12, 8GB RAM, 4 CPU, WordOps 3.18 fraichement installé

Contraintes : Budget limité, besoin d'uptime 99.9%

—

6.2 Migration vers WordOps

Je souhaite migrer mon infrastructure WordPress existante vers WordOps.

Configuration actuelle :
Setup : [cPanel, Plesk, manuel, autre]
Web server : [Apache, Nginx]
PHP : [version]
Nombre de sites : [X]
Base de données : [MySQL, MariaDB]

Sites à migrer :
[domain1.com] - [type : blog, ecommerce, etc.] - [taille DB]
[domain2.com] - [type] - [taille DB]

Contraintes de migration :
Downtime acceptable : [durée maximale]
Moment optimal : [weekend, nuit, etc.]
DNS : [déjà configuré, à configurer]
Backup existant : [oui/non]

Risques identifiés :
[LISTER VOS PRÉOCCUPATIONS]

Fournir :
Plan de migration étape par étape
Commandes pré-migration (backups)
Procédure de migration WordOps
Checklist de validation post-migration
Plan de rollback si problème
Estimation de durée

Priorité : [vitesse, sécurité des données, zéro downtime]

Exemple d’utilisation :

Configuration actuelle :
Setup : Configuration manuelle (Nginx + PHP-FPM)
Web server : Nginx 1.18
PHP : 8.1
Nombre de sites : 5 WordPress
Base de données : MariaDB 10.6

Sites à migrer :
example.com - Blog - 500MB DB
shop.example.com - WooCommerce - 2GB DB
staging.example.com - Staging - 300MB DB

Contraintes :
Downtime acceptable : Maximum 2 heures
Moment optimal : Dimanche 2h-6h du matin
DNS : Cloudflare (déjà configuré, juste à pointer)
Backup : Oui (backups quotidiens via script custom)

Risques identifiés :
Le site WooCommerce a des customisations Nginx importantes
Certificats SSL wildcards à transférer

Priorité : Sécurité des données (vérification exhaustive)

—

7. Debugging & Résolution de Problèmes

7.1 Debug WordPress Avancé

Mon site WordPress rencontre un problème que je n'arrive pas à résoudre.

Symptômes observés :
[DÉCRIRE PRÉCISÉMENT]

Informations système :
WordPress : [version]
PHP : [version]
Serveur : [Nginx/Apache, version]
Plugins actifs : [liste]
Thème : [nom]

Logs disponibles :

[COLLER : debug.log, error.log, access.log pertinents]

Tests déjà effectués :
[ ] Désactivation plugins
[ ] Thème par défaut
[ ] WPDEBUG activé

[ ] Vidage cache
[ ] Autre : [préciser]

Code modifié récemment :

[LANGAGE]
[COLLER LE CODE SI PERTINENT]

Demande :
Diagnostic précis du problème
Solution immédiate (workaround si nécessaire)
Fix permanent
Prévention (monitoring, tests)

Urgence : [critique, haute, normale]

Exemple d’utilisation :

Symptômes : White Screen of Death (WSOD) sur toutes les pages depuis 2h.
Aucun message d'erreur visible.

Informations système :
WordPress : 6.4.2
PHP : 8.2
Serveur : Nginx 1.24, WordOps
Plugins actifs : ~20 (liste complète disponible)
Thème : Custom développé en interne

Logs :
PHP Fatal error: Uncaught Error: Call to undefined function getcustomfield()
in /var/www/site/htdocs/wp-content/themes/custom/functions.php:145

Tests déjà effectués :
Tentative de désactivation plugins via FTP (échec)
WPDEBUG activé mais WSOD persiste
Vidage cache serveur (Redis)

Code modifié : Ajout d'une fonction dans functions.php ce matin

Urgence : CRITIQUE (site production down)

—

7.2 Optimisation Performance WordPress

Mon site WordPress est lent et je cherche à optimiser ses performances.

Métriques actuelles :
PageSpeed score : [X/100]
Time to First Byte (TTFB) : [X]s
Largest Contentful Paint (LCP) : [X]s
First Input Delay (FID) : [X]ms
Cumulative Layout Shift (CLS) : [X]

Outils utilisés :
[GTmetrix, Google PageSpeed, WebPageTest, etc.]

Configuration actuelle :
Hébergement : [type et specs]
Cache : [plugin utilisé ou non]
CDN : [oui/non, lequel]
Optimisation images : [oui/non, méthode]
Minification : [oui/non]

Analyse Query Monitor (si disponible) :

[COLLER RAPPORT QUERY MONITOR]

Contraintes :
Budget : [gratuit uniquement, budget flexible]
Modifications serveur : [autorisées, non autorisées]
Plugins premium : [acceptables, non]

Objectif cible :
PageSpeed : [X]/100, LCP < [X]s, TTFB < [X]s

Fournir :
Analyse détaillée des bottlenecks
Plan d'optimisation priorisé
Configuration recommandée (cache, CDN, etc.)
Code optimisé si nécessaire
Tests de validation

Type de site : [blog, e-commerce, corporate, autre]

Exemple d’utilisation :

Métriques actuelles :
PageSpeed (mobile) : 45/100
TTFB : 2.8s
LCP : 5.2s
FID : 180ms
CLS : 0.25

Outils : GTmetrix, Chrome DevTools

Configuration actuelle :
Hébergement : VPS Debian 12, 4GB RAM, WordOps
Cache : WP Super Cache (config par défaut)
CDN : Non
Optimisation images : Non systématique
Minification : Partielle

Contraintes :
Budget : Flexible (solutions gratuites préférées)
Modifications serveur : Autorisées (accès root)
Plugins premium : Acceptables si ROI démontré

Objectif cible : PageSpeed 90+/100, LCP < 2.5s, TTFB < 600ms

Type de site : Blog média avec beaucoup d'images (magazine en ligne)

---

8. Documentation Technique

8.1 Architecture Decision Record (ADR)

Je dois documenter une décision technique importante pour mon projet.

Contexte du projet :
[DÉCRIRE LE PROJET]

Décision à documenter :
[QUELLE DÉCISION TECHNIQUE]

Alternatives considérées :
[Option 1]
[Option 2]
[Option 3]

Critères d'évaluation :
Performance
Maintenabilité
Coût
Complexité
[Autres critères]

Décision retenue : [Option X]

Raisons :
[EXPLIQUER POURQUOI]

Fournir un ADR structuré selon le format standard :
Status : [Proposed, Accepted, Deprecated, Superseded]
Context : Situation et problème
Decision : Quelle solution
Consequences : Impacts positifs et négatifs

Format : Markdown, prêt à commit dans /docs/adr/

Exemple d'utilisation :

Contexte : Plugin WordPress de formulaires avancés avec 10k+ installations actives

Décision : Choix du système de validation côté serveur

Alternatives :
Validation custom maison
Symfony Validator Component
Respect/Validation
WordPress native validation

Critères :
Performance (critique pour UX)
Facilité d'extension (règles custom fréquentes)
Compatibilité WordPress
Taille de la dépendance
Documentation et maintenance

Décision retenue : Respect/Validation

Raisons :
Léger (pas de dépendances lourdes)
API fluide et intuitive
Facilité d'ajouter règles custom
Bien maintenu et documenté
Pas de conflit avec WordPress

---

8.2 Onboarding Documentation

Je dois créer une documentation d'onboarding pour de nouveaux développeurs
rejoignant le projet.

Informations projet :
Type : [plugin, thème, projet complet]
Stack : [technologies utilisées]
Taille équipe : [X développeurs]
Repository : [GitHub, GitLab, etc.]

Niveau cible :
[junior, intermédiaire, senior, mixte]

Sections nécessaires :
Setup environnement local
Architecture du projet
Standards et conventions
Workflow Git et déploiement
Tests et CI/CD
Ressources et documentation

Spécificités du projet :
[DÉCRIRE LES PARTICULARITÉS]

Fournir :
Documentation markdown complète
Scripts d'installation automatisés
Checklist premier jour / première semaine
FAQ développeurs
Liens ressources utiles

Ton : [formel, informel, technique]
Format : [README.md, Wiki, docs/ folder]

Exemple d'utilisation :

Informations projet :
Type : Plugin WordPress commercial (système de réservation)
Stack : PHP 8.2, React, TypeScript, WordPress REST API, Jest, PHPUnit
Taille équipe : 5 développeurs
Repository : GitHub (privé)

Niveau cible : Intermédiaire à senior

Spécificités :
Build process custom avec Webpack
Tests obligatoires avant merge
Environnement Docker pour dev local
CI/CD avec GitHub Actions
Code review systématique

Ton : Technique mais accueillant
Format : docs/ folder avec table des matières dans README.md

---

Guide d'Utilisation des Prompts

Bonnes Pratiques

• Contexte Précis : Plus vous donnez de contexte, meilleure sera la réponse
• Exemples Concrets : Incluez du code, logs, erreurs actuels
• Objectifs Clairs : Spécifiez ce que vous attendez comme résultat
• Contraintes : Mentionnez limitations (budget, temps, technique)

Optimisation des Réponses IA

Pour Claude.ai :

• Utilisez des blocs de code avec syntaxe (`php, `bash)
• Structurez avec des titres et listes
• Demandez des étapes numérotées pour processus complexes
• N'hésitez pas à demander des clarifications

Pour ChatGPT :

• Soyez explicite sur le format de sortie souhaité
• Utilisez "Agis comme un expert [DOMAINE]" pour contexte
• Demandez des validations étape par étape si complexe
• Précisez la version des technologies (PHP 8.2, WordPress 6.4)

Workflow Recommandé

• Copier le prompt de ce document
• Personnaliser avec votre contexte spécifique
• Coller dans Claude.ai ou ChatGPT
• Itérer : Affiner avec questions de suivi si besoin
• Valider : Tester la solution avant production

Astuces Avancées

Prompt Chaining : Pour tâches complexes, divisez en plusieurs prompts :

1. Analyse du problème → Obtenir diagnostic
Solution proposée → Obtenir code
Tests et validation → Obtenir tests unitaires
Documentation → Obtenir docs

Context Building : Construisez contexte progressivement :

Premier prompt : "Voici mon architecture..."
Deuxième prompt : "Maintenant, avec ce contexte, j'ai un problème..."

Few-Shot Learning : Donnez des exemples du style souhaité :

"Voici comment je documente habituellement :
[EXEMPLE]

Maintenant, documente ce code dans le même style :"

---

Ressources Complémentaires

Documentation Officielle

• WordPress Developer Handbook
• WordPress Coding Standards
• WordOps Documentation
• Debian Administrator's Handbook
• Git Documentation

Outils Recommandés

Développement Local :

• LocalWP / Lando / Docker
• PHP CodeSniffer (PHPCS)
• PHP Mess Detector (PHPMD)

Sécurité :

• WPScan
• Fail2ban
• Lynis (audit sécurité)

Performance :

• Query Monitor
• GTmetrix / PageSpeed Insights
• New Relic / Blackfire.io

Git :

• GitKraken / Sourcetree
• Conventional Commits
• Semantic Versioning

---

Changelog

Version 1.0 (2025-12-18)

• Création initiale
• 8 catégories de prompts
• 18 templates professionnels
• Exemples d'utilisation complets
• Guide d'utilisation et bonnes pratiques

---

Contribution

Ces prompts sont vivants et peuvent être améliorés. Si vous développez des
variantes efficaces, documentez-les pour usage futur.

Format de contribution suggéré :

X.X Titre du Nouveau Prompt

[Prompt template]

Exemple d'utilisation :
[Exemple concret]

Cas d'usage idéal : [Description]
Niveau requis : [Débutant/Intermédiaire/Avancé]

---

Auteur : Créé pour le projet youarewelcom
License : Usage interne et éducatif
Dernière mise à jour : 2025-12-18