# Dix sites d’une agence partagent un même prompt : qui le fait évoluer

> Versionner, tester et faire évoluer un prompt partagé entre plusieurs sites sans que chacun n'en garde une variante non documentée.

- Auteur : WordPress Développement
- Publié le : 2024-05-15
- Mis à jour le : 2024-05-15
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/dix-sites-agence-prompt-commun-versioning/

## L’essentiel

- Un prompt copié dix fois devient dix prompts différents en six mois
- Un dépôt central évite la dérive silencieuse
- Chaque site doit pouvoir surcharger sans dupliquer

`Vous utilisez la version 3 ou la version 7 du prompt de relecture ?` Cette question, posée en réunion d'équipe, a suffi à révéler qu'aucune des dix personnes présentes ne pouvait répondre avec certitude. Chacune avait, à un moment, copié le fichier de prompt d'un site vers un autre, puis l'avait légèrement ajusté pour un besoin ponctuel.

Le prompt partagé entre plusieurs sites d'une même agence part toujours d'une bonne intention : mutualiser un texte qui fonctionne, éviter de réinventer la formulation à chaque projet. Mais sans mécanisme de gouvernance, cette mutualisation initiale se transforme en dix variantes non documentées en quelques mois, chacune corrigeant un défaut différent sans que les autres sites n'en bénéficient.

## Le symptôme d'un prompt copié-collé

Sur un parc que nous avons repris, le prompt de génération de résumés d'articles existait en version fichier PHP, codé en dur dans une constante, sur chacun des dix sites concernés. Un diff entre les dix fichiers a montré des écarts allant d'une simple reformulation à des instructions contradictoires — l'un limitait la sortie à cent mots, un autre à deux cents, sans qu'aucune décision documentée n'explique la différence.

Le problème ne vient pas de la copie initiale, légitime pour démarrer vite, mais de l'absence de retour vers une source commune. Chaque correction reste locale, invisible aux neuf autres sites, alors qu'elle corrige souvent un défaut générique du prompt d'origine.

## Une arborescence pour centraliser sans rigidifier

> L'essentiel à retenir : Un prompt copié dix fois devient dix prompts différents en six mois ; Un dépôt central évite la dérive silencieuse ; Chaque site doit pouvoir surcharger sans dupliquer

La solution retenue a consisté à sortir les prompts du code de chaque site pour les stocker dans un dépôt Git central, organisé par usage plutôt que par site, avec un mécanisme de surcharge locale explicite.

```
prompts/
├── core/
│   ├── resume-article.md
│   ├── suggestion-titre.md
│   └── moderation-commentaire.md
├── overrides/
│   ├── site-a/resume-article.md
│   └── site-c/moderation-commentaire.md
└── CHANGELOG.md
```

Chaque site charge le prompt du dossier `core` par défaut, et ne va chercher dans `overrides` que s'il existe un fichier portant son identifiant. Cette structure rend visible, d'un simple coup d'œil dans le dépôt, quels sites s'écartent du prompt commun et pourquoi — chaque fichier de surcharge doit être accompagné d'un commentaire expliquant la raison de l'écart.

## Qui a le droit de modifier le prompt commun

Techniquement, n'importe qui avec un accès au dépôt peut modifier `core/resume-article.md`. Organisationnellement, ce pouvoir doit rester limité à une personne référente par usage, qui valide les propositions de modification via une revue de code classique avant fusion.

- Une personne référente par catégorie de prompt, pas par site
- Toute modification du dossier `core` passe par une revue avant fusion
- Un changelog daté accompagne chaque évolution du prompt commun
- Les surcharges locales sont revues tous les trimestres pour vérifier qu'elles sont encore justifiées

## Déployer une évolution sur dix sites sans rupture

Faire évoluer un prompt commun sans casser dix sites différents suppose de traiter le changement comme une mise à jour de dépendance : un numéro de version, un changelog, et une période de recouvrement où l'ancienne et la nouvelle version coexistent le temps que chaque site confirme la compatibilité.

> Sur nos projets, aucune évolution du prompt commun n'est déployée un vendredi, et aucune n'est déployée simultanément sur les dix sites : on avance site par site, avec un jour d'observation entre chaque déploiement.

## Ce que cette organisation ne résout pas

Centraliser les prompts n'empêche pas un prompt de mal vieillir face à un nouveau modèle, ni de produire des sorties différentes selon le fournisseur de LLM appelé. La gouvernance du texte du prompt et l'évaluation automatisée de ses résultats restent deux chantiers distincts, à ne pas confondre sous prétexte qu'ils partagent le même fichier source.

## Notre verdict

Un prompt partagé entre plusieurs sites ne survit pas à l'absence de gouvernance, même avec la meilleure volonté de chaque équipe. Un dépôt central, une hiérarchie claire entre version commune et surcharge locale, et une personne référente par usage suffisent à transformer dix variantes silencieuses en une seule source maintenue.