Comment un PRD guide un CMS et le développement assisté par IA

Publié le 2026-04-14

Ce CMS a été conçu à partir d’un prompt initial servant de PRD, puis implémenté par itérations courtes. L’intérêt de cette approche n’est pas seulement la vitesse d’exécution : c’est surtout la traçabilité des décisions techniques entre l’intention produit, l’architecture et le code réellement livré.

Qu’est-ce qu’un PRD

PRD signifie Product Requirements Document. C’est un document qui formalise ce qu’il faut construire, dans quel périmètre, avec quelles contraintes, et selon quels critères de validation.

En pratique, un PRD utile pour une équipe technique décrit :

• le périmètre fonctionnel
• les contraintes techniques
• les critères de réussite
• les non-objectifs (ce qu’il ne faut pas faire)
• les hypothèses d’architecture

Un PRD n’est pas un substitut au code, ni un document de communication vague. C’est une référence opérationnelle qui réduit les ambiguïtés et limite les dérives de portée.

Le prompt initial comme PRD opérationnel

Le prompt initial de ce projet a joué ce rôle de manière explicite en fixant :

• une architecture auto-hébergée et durable
• une séparation claire entre site et API
• Markdown comme source de vérité éditoriale
• plusieurs canaux de publication (fichier, e-mail, API)
• absence de dépendance SaaS et de lock-in
• simplicité d’exploitation sur VPS Linux

Les noms de domaines réels ont été anonymisés dans cette logique documentaire :

• site.example.tld pour le frontend
• api.example.tld pour le backend

L’anonymisation conserve la valeur pédagogique tout en évitant d’exposer des détails d’exploitation.

Du PRD à l’architecture cible

Le passage du PRD à l’implémentation s’est traduit par des choix d’architecture concrets :

• site statique et applicatif servi par Astro
• API applicative exposée par FastAPI sur un domaine dédié
• contenu éditorial exclusivement stocké en fichiers Markdown
• données applicatives optionnelles en SQLite, séparées du contenu éditorial
• routage HTTP/HTTPS via Traefik, sans logique SMTP dans le proxy

Cette séparation des responsabilités évite le couplage entre publication éditoriale, logique applicative et transport réseau.

Pourquoi cette approche fonctionne

Utiliser un prompt comme PRD permet d’accélérer sans perdre le contrôle, à condition de garder une discipline d’ingénierie.

Le cycle d’exécution retenu est simple et reproductible :

1. formaliser les exigences dans un document unique
2. implémenter par incréments fonctionnels
3. tester les flux réels (pas seulement des cas théoriques)
4. corriger la documentation dès qu’un écart apparaît
5. nettoyer l’historique (branches, artefacts de test, commits ciblés)

Résultat : un système lisible, portable, et auditable, avec une documentation alignée sur le comportement effectif.

Développement assisté par IA : ce que ça change

Le développement assisté par IA ne remplace pas l’ingénierie ; il change surtout la dynamique d’exécution.

Sur ce projet, l’IA a été utilisée comme accélérateur sur des tâches à forte fréquence :

• génération et refactorisation de scripts
• vérification de cohérence entre code et documentation
• préparation de commits propres
• diagnostic d’erreurs d’intégration (SMTP, environnement, URL)

Le gain réel vient de la réduction du temps entre hypothèse, implémentation et validation. Autrement dit, l’IA comprime la boucle de feedback, mais la qualité dépend toujours des exigences initiales et du niveau de vérification.

Bonnes pratiques à retenir

Le développement assisté par IA reste fiable quand quelques règles simples sont respectées :

• garder un PRD explicite et versionné
• exiger des validations techniques réelles (tests, logs, déploiement)
• documenter ce qui est effectivement implémenté
• isoler les changements par branche et par commit
• supprimer les artefacts de test une fois la fonctionnalité validée

Une formule résume bien l’approche : IA rapide, ingénierie rigoureuse.

Limites et vigilance

Le principal risque du développement assisté par IA n’est pas l’erreur syntaxique, mais la dérive silencieuse :

• documentation non alignée avec le code
• hypothèses implicites non validées
• accumulation d’artefacts de test en production

La contre-mesure reste classique : revues ciblées, tests de flux complet, et hygiène Git stricte.

Conclusion

Un PRD bien écrit transforme un prompt en feuille de route opérationnelle. Et une IA bien utilisée transforme cette feuille de route en livrables concrets, sans sacrifier la qualité.

Ce projet montre qu’un CMS sobre, durable et multi-canaux peut être construit rapidement à condition de conserver une discipline forte sur trois axes : intention explicite, validation terrain et documentation à jour.