← Tous les articles
étude de casWordPressCloudflare

WordPress + Cloudflare : moderniser la plateforme AQCAMO sans tout reconstruire

Pour l’AQCAMO, j’ai conservé WordPress pour le site et les comptes membres, puis développé des outils spécialisés pour les médicaments et la formation. Voici pourquoi.

Étude de cas · Novembre 2026. Certains services continuent d’évoluer.

Intégration de WordPress et Cloudflare pour les médicaments, les documents et la formation AQCAMO

Pour découvrir l’organisme et ses ressources, visitez le site officiel de l’AQCAMO.

Garder WordPress là où il est utile

Dans un autre article, j’explique pourquoi cabana.dev n’utilise plus WordPress. Pour l’AQCAMO, j’ai fait un choix différent : le conserver pour le site public et les comptes membres, puis développer des applications pour les documents et la formation.

Le site doit rester bilingue, présenter l’association et permettre la gestion des adhésions. WordPress remplit ces rôles. Le remplacer aurait ajouté une migration des comptes et une reconstruction des parcours, sans répondre directement au besoin de mieux gérer les formulaires.

Partir du travail à faire

J’ai commencé par les situations concrètes : retrouver un médicament, remplacer un formulaire dans les deux langues, traiter une demande portant sur plusieurs fiches et savoir où en est un participant dans sa formation.

Ces tâches demandent des règles précises. Un même PDF peut servir à plusieurs médicaments; une demande peut être traitée en plusieurs fois; un ancien dossier de formation ne doit pas être associé au mauvais compte. C’est sur ces règles que j’ai construit les outils.

Workers, D1 et R2 : chacun son rôle

Les applications utilisent trois services Cloudflare. Workers exécute la logique et vérifie les autorisations. D1 conserve les données structurées. R2 stocke les documents.

Ce qui reste dans WordPress et ce qui relève des applications
ComposantRôle dans le projet
WordPressPages publiques, contenu bilingue, adhésions et identité des membres
WorkersRequêtes applicatives, droits d’accès et traitement des demandes
D1Médicaments, associations documentaires, historique et progression
R2Fichiers PDF utilisés par les applications

Cette répartition permet de faire évoluer la gestion documentaire sans devoir refaire les pages institutionnelles.

Pourquoi la recherche est plus rapide à l’usage

Une recherche de médicament n’a pas besoin de charger son formulaire. Elle doit d’abord retrouver une fiche à partir d’un nom, d’un DIN ou d’une compagnie.

Le Worker interroge les données de D1 et renvoie les résultats sans passer par le chargement habituel d’une page WordPress et de ses extensions. Le PDF stocké dans R2 est récupéré séparément, lorsque le membre autorisé l’ouvre.

Le gain vient surtout de cette recherche ciblée et du traitement des requêtes. R2 sert au stockage des fichiers; ce n’est pas un moteur de recherche. Dans les essais du projet, le parcours est sensiblement plus fluide. Je ne donne pas de pourcentage de gain : il faudrait comparer les deux systèmes avec des mesures reproductibles.

Un seul compte ne veut pas dire les mêmes droits partout

WordPress reste la référence pour l’identité. Les connexions entre le site et les applications sont conçues pour qu’un membre approuvé n’ait pas à créer une deuxième inscription.

Chaque application doit néanmoins vérifier les droits côté serveur. L’accès à un formulaire réservé, le suivi d’une formation et les fonctions de gestion correspondent à des autorisations différentes. Masquer un bouton dans l’interface ne suffit pas à protéger une ressource.

Préparer la prochaine mise à jour du PDF

Le travail ne s’arrête pas au téléversement d’un fichier. J’ai prévu le remplacement ou la fusion des documents, leur association aux médicaments concernés et la conservation d’un historique.

Quand un document devient la version en vigueur, il doit pouvoir être repris lors de la demande suivante. Les langues et les catégories restent distinctes pour éviter de confondre un formulaire d’inscription avec un document d’information.

Reprendre les formations avec leurs historiques

Le parcours reprend des contenus auparavant dans LearnDash : une introduction, douze modules, des présentations et des questionnaires. La nouvelle plateforme gère les résultats, le déblocage des étapes, les tentatives et l’attestation finale.

La reprise des anciens dossiers demande une vérification supplémentaire. Un identifiant numérique peut changer de sens lors d’une migration WordPress. Le rapprochement des historiques avec les comptes autorisés doit donc être contrôlé; leur préservation intégrale reste à confirmer dossier par dossier.

Préparer la mise en service et le retour arrière

Le code est versionné dans GitHub, avec des tests automatisés et des compilations de vérification. Les essais sur les environnements de préparation servent à valider les parcours avant l’ouverture aux membres. La séparation effective des données et les configurations de production font partie des contrôles de lancement.

Les sauvegardes et les procédures de restauration font aussi partie du projet. Revenir à une version de code ne doit pas écraser les progressions ou les mises à jour enregistrées depuis. Les liens, les redirections et l’indexation des pages publiques demandent leurs propres vérifications.

Ce que je retiens de ce projet

WordPress reste utile pour les contenus et les membres. Les applications sur mesure prennent en charge les tâches qui demandent leurs propres données et processus. Ce choix répond aux besoins de l’AQCAMO; une autre organisation pourrait très bien rester entièrement dans WordPress.

Voir la présentation du projet AQCAMO, côté membres et responsables →

Votre site doit évoluer sans tout recommencer?

Parlons de votre situation et des possibilités de modernisation.

Discutons-en →