Dawap CMS : structurer 83 pages en trois langues sans perdre le contrôle SEO

1. Dawap, premier utilisateur de son propre socle de publication

Confronter le modèle à cinq métiers web et à trois langues dès le départ

Dawap développe des intégrations API, accompagne des vendeurs marketplace, construit des marketplaces opérateur, réalise des applications web et intervient sur la performance SEO technique. Ces cinq expertises ont chacune leurs familles de pages, leur vocabulaire et leurs prolongements commerciaux.

À ces services s’ajoutent les produits Ciama, Daspeed et Dapulse, les actualités, les projets, la présentation de l’agence, sa méthode et ses technologies. Un CMS destiné à ce périmètre doit donc représenter aussi bien une page d’accueil qu’un produit, une ressource, une catégorie de service ou une page de profondeur trois.

Le projet est interne, mais son exigence est directement transposable à un site client complexe : conserver une architecture intelligible, publier plusieurs langues, contrôler les métadonnées au bon niveau et permettre à une API ou à un back-office d’écrire sans contourner les règles métier.

Cette réalisation complète le travail visible sur la création de sites internet sur mesure. Le rendu public reste une responsabilité ; Dawap CMS se concentre ici sur la structure qui doit l’alimenter proprement.

2. Trois étapes entre le 22 mai et le 5 août 2026

Stabiliser le domaine, suivre l’architecture du site puis moderniser le contrôle humain

La première étape du 22 mai 2026 installe le domaine CMS et sa persistance. Langue, nœud et traduction possèdent des contrats de lecture et d’écriture distincts. Les objets de commande restent séparés des entités Doctrine afin que les validations métier précèdent la sauvegarde.

La seconde étape ajoute les commandes d’amorçage, l’authentification, l’API de création et les premières vues d’administration. De juin à fin juin, l’arbre initial évolue avec les familles de services réellement publiées, notamment la nouvelle couverture SEO technique.

Le 5 août, le poste de travail d’administration est modernisé et le neuvième scénario d’intégration rejoint la suite. Les tests vérifient alors le trajet complet : création dans le domaine, écriture authentifiée, refus des doublons, construction de l’arbre, absence des langues requises, protection de l’administration et consultation des nœuds et traductions.

3. Passer d’un ensemble de routes à un véritable modèle éditorial

Ne plus laisser l’identité d’une page dépendre uniquement de son adresse

Sur un site codé gabarit par gabarit, la route, le contrôleur, le contenu et les métadonnées peuvent évoluer ensemble. Cette proximité reste efficace tant que le volume est maîtrisé, mais elle rend chaque nouvelle langue et chaque migration plus coûteuse à coordonner.

Dawap CMS introduit une couche intermédiaire. Le nœud dit ce qu’est la page dans l’architecture : accueil, solution, produit, ressource ou page d’agence. La traduction dit comment cette intention s’exprime dans une langue donnée : chemin, titre, H1, données sociales, indexation et publication.

Cette distinction résout d’abord un problème d’identité. Le service « création marketplace » demeure le même objet lorsqu’il devient « marketplace creation » ou « creación marketplace ». Les équipes peuvent raisonner sur une seule responsabilité sans imposer le même slug aux trois publics.

Elle prépare aussi les évolutions futures. Une URL peut être ajustée, une version mise en brouillon ou un gabarit remplacé sans perdre la relation avec le parent, les enfants et les autres langues.

4. Trois risques à éliminer avant de migrer les contenus

Doublons de chemins, arbres incohérents et SEO dissocié de la publication

Le premier risque est l’unicité. Deux contenus différents ne doivent pas occuper le même chemin dans une même langue. À l’inverse, deux langues doivent pouvoir employer des chemins distincts pour le même nœud sans créer deux identités éditoriales.

Le deuxième risque est hiérarchique. Un enfant déclaré en profondeur trois doit réellement dépendre d’un parent de profondeur deux. Sans contrôle, une importation peut produire un fil d’Ariane faux, une navigation impossible à reconstruire ou une branche orpheline.

Le troisième risque concerne la publication. Une page possède un statut, une date, une directive robots, une priorité de sitemap et une fréquence de changement. Reporter ces décisions après la migration reviendrait à créer d’abord la page, puis à découvrir ensuite si elle devait être indexée.

Le projet traite donc la cohérence avant le volume. C’est ce choix qui permet d’utiliser ensuite la même API pour un import, un outil éditorial ou une commande d’initialisation sans obtenir trois comportements différents.

5. Quatre objectifs pour la première fondation

Créer, localiser, sécuriser et contrôler avant d’étendre

Le premier objectif consiste à représenter toute page par une clé stable, un type, un mode de rendu, un statut, une position, une profondeur et, lorsque nécessaire, un parent. L’arbre devient ainsi une donnée métier plutôt qu’un effet secondaire de la navigation.

Le deuxième rend le multilingue obligatoire dès la création. Tant que français, anglais et espagnol sont actifs, un nœud incomplet dans l’une de ces langues ne peut pas entrer silencieusement dans l’arbre initial.

Le troisième rassemble routage, présentation et SEO dans la traduction concernée. Chaque langue peut gérer son slug, son chemin, son title, sa meta description, sa canonique, son image sociale, ses directives robots et ses informations de sitemap.

Le quatrième ouvre ces capacités de manière contrôlée : authentification par jeton pour l’API, rôle super-administrateur pour le back-office, transactions pour l’écriture et tests d’intégration sur les refus les plus structurants.

6. Un premier lot volontairement centré sur le squelette du site

Prouver la cohérence de l’arbre avant la migration éditoriale complète

La livraison établit les langues, les nœuds, leurs traductions, les données de présentation et de référencement, l’accès API et les écrans de consultation. Elle contient aussi des structures pour des résumés, des blocs, des articles et des études de cas.

Le parcours abouti de ce lot est la création d’un nœud et de toutes ses traductions. L’édition publique complète de chaque type de contenu, la migration de l’ensemble des textes et la gestion avancée des médias restent des étapes séparées.

Cette limite évite un basculement prématuré. Le site public continue de fonctionner pendant que le nouveau modèle peut être amorcé, inspecté et testé. La migration future dispose ainsi d’une cible connue au lieu de découvrir ses règles en déplaçant les contenus.

Pour un produit interne, cette discipline compte autant qu’une longue liste de fonctions : une fondation courte mais cohérente réduit les reprises lorsque les équipes brancheront l’édition et le rendu.

7. Donner au contenu une identité indépendante de son URL

Une clé stable pour relier type, position, parent et traductions

Chaque nœud reçoit une clé unique, par exemple `integration-api` ou `agence.technologies`. Cette clé sert aux relations internes et reste stable même si le titre ou le chemin français évolue.

Le type distingue l’accueil, une page de destination, une solution, un produit, une ressource ou une page d’agence. La position ordonne les éléments ayant le même parent, tandis que la profondeur rend la structure contrôlable lors de l’écriture.

Le parent forme un arbre réel en base. Les vues d’administration peuvent donc afficher une racine, descendre vers ses enfants et reconstruire un fil de navigation sans déduire les relations à partir de chaînes d’URL.

Trois états — brouillon, publié et archivé — accompagnent le cycle de vie. Un contenu peut sortir de la publication sans perdre son identité ni les relations nécessaires à son suivi.

8. Faire du français, de l’anglais et de l’espagnol des versions liées

Une traduction par langue active, avec son propre chemin public

La commande d’amorçage crée trois langues actives : `fr_FR`, `en_GB` et `es_ES`. Le français est défini comme langue par défaut, mais chaque langue conserve son libellé et sa position.

Lorsqu’un nœud est ajouté, le cas d’usage compare les traductions reçues à la liste des langues actives. Une langue inconnue est refusée, une langue répétée est signalée et une version manquante produit une erreur localisée.

La relation unique entre un nœud et une langue empêche deux traductions françaises concurrentes pour la même page. Une seconde contrainte garantit aussi qu’un chemin ne peut appartenir qu’à une traduction dans une langue donnée.

Le multilingue devient ainsi une propriété de conception, pas une duplication tardive. L’équipe connaît dès la création les versions présentes et les adresses qui les représentent.

9. Placer les décisions SEO au niveau de chaque traduction

Adresse, indexation et données sociales suivent la langue réellement publiée

Une traduction stocke son slug et son chemin complet. Elle porte aussi le titre éditorial, le H1, le meta title et la meta description, ce qui permet d’adapter la promesse à la langue au lieu de traduire mécaniquement un seul champ générique.

Le chemin canonique, le titre Open Graph, sa description, son image et la directive robots appartiennent à la même version. Les décisions de partage ou d’indexation restent donc alignées avec l’adresse consultée.

Le sitemap est préparé au même endroit avec une fréquence de changement, une priorité comprise entre 0 et 1 et une date de dernière modification. La date de publication et le statut complètent le passage du brouillon à la page exposable.

Cette granularité prolonge notre travail sur le SEO programmatique à l’échelle : la qualité ne dépend pas d’une correction globale appliquée après coup, mais de règles présentes dans chaque unité publiable.

10. Contrôler la profondeur au lieu de la deviner depuis le chemin

Un parent obligatoire dès que le contenu quitte la racine

La profondeur ne peut pas être négative. À partir du niveau un, le parent devient obligatoire. Le cas d’usage vérifie ensuite que ce parent existe et que sa profondeur se situe exactement un niveau au-dessus.

Une page ne peut donc pas se déclarer enfant d’un élément absent ni sauter arbitrairement du niveau un au niveau trois. Ces contrôles maintiennent l’arbre utilisable pour le back-office, la navigation et les futures migrations.

L’accueil reçoit une règle supplémentaire : il ne peut exister qu’un seul nœud de type `home`, et ses chemins localisés restent vides. La racine ne concurrence ainsi aucune autre page dans une langue.

Le slug doit enfin correspondre au dernier segment du chemin lorsqu’ils sont tous deux renseignés. Une erreur entre `/api-integration` et un slug différent est arrêtée avant la persistance.

11. Prévoir deux modes de rendu sans les confondre

Gabarit Twig stable ou contenu structuré composable

Le nœud accepte deux modes : `static_twig` et `structured_content`. Le premier relie la page à une clé de template ; le second prépare un rendu construit à partir de données structurées.

Lorsqu’un nœud choisit le mode Twig, la clé de template devient obligatoire. Cette règle empêche de publier une page déclarée statique sans savoir quel gabarit doit la représenter.

L’arbre initial utilise volontairement les gabarits Twig existants pour l’accueil et les pages de service. Le modèle peut donc reprendre progressivement le site actuel avant que tous les contenus ne basculent vers des blocs structurés.

Ce choix réduit le risque de migration : architecture éditoriale et moteur de rendu peuvent évoluer à des rythmes différents tout en partageant la même identité de page.

12. Créer un nœud et ses traductions dans une seule transaction

Un POST authentifié, une validation métier, une réponse exploitable

Le point d’entrée `POST /api/nodes` reçoit la clé, le type, le mode de rendu, le parent, la position, la profondeur et la collection de traductions. Il convertit chaque version locale vers la même demande métier utilisée par les commandes internes.

L’écriture s’exécute dans une transaction Doctrine. Si une erreur survient pendant la création, le système peut annuler l’ensemble au lieu de conserver un nœud sans toutes ses traductions.

Une réponse valide renvoie la clé, le type, le rendu, le template, la profondeur, la position et, pour chaque traduction, la langue, le chemin et le slug. L’appelant obtient les identifiants fonctionnels dont il a besoin pour poursuivre un import.

Une validation refusée produit un statut 400 et rattache les messages aux champs concernés, y compris à une traduction précise. L’API devient un contrat de publication plutôt qu’un simple accès direct aux tables.

13. Refuser tôt les incohérences qui coûteraient cher après publication

Clés, chemins, langues, statuts et données de sitemap contrôlés ensemble

La clé vide ou déjà utilisée, le type absent, un mode de rendu inconnu et un statut hors de la liste autorisée sont refusés. Le même principe s’applique au parent, à la profondeur et à l’unicité de l’accueil.

Pour les traductions, le titre est obligatoire. Le chemin n’accepte que des segments normalisés en minuscules, chiffres et tirets. Le slug doit rester cohérent avec ce chemin, et la combinaison langue–chemin doit être unique.

Les fréquences de sitemap sont limitées aux valeurs connues par le protocole. La priorité accepte de 0 à 1 avec une seule décimale, ce qui empêche une valeur libre de casser ou de rendre incohérent le futur flux XML.

Chaque erreur possède un code stable. Un back-office ou un import peut ainsi expliquer « chemin déjà utilisé » ou « langue manquante » sans dépendre du texte interne d’une exception.

14. Séparer la session du back-office et les jetons de l’API

Deux usages, deux parcours d’accès

Le back-office utilise une connexion par formulaire protégée par CSRF. L’administration sous `/admin` exige le rôle super-administrateur, ce qui réserve la consultation de l’arbre et des traductions aux comptes prévus.

L’API dispose de son propre couple de jetons signés. La connexion vérifie que l’utilisateur existe, qu’il est actif et que son mot de passe correspond avant de produire un jeton d’accès de quinze minutes et un jeton de renouvellement de sept jours.

Le point d’entrée de création attend un jeton d’accès Bearer valide. Une signature incorrecte, un type de jeton inadéquat ou une date d’expiration dépassée conduit à un refus sans exécuter le cas d’usage.

Cette séparation correspond aux deux contextes : une personne explore le back-office avec une session ; un outil d’import échange avec l’API sur une durée bornée. Notre offre d’intégration d’authentification et de sécurité prolonge ce type de frontière.

15. Inspecter l’arbre sans parcourir la base de données

Recherche, navigation par parent et détail des versions localisées

La liste d’administration affiche la racine et ses premiers niveaux, avec leurs parents, enfants et traductions chargés dans la même lecture. Une recherche peut porter sur la clé, le type, le titre localisé ou le chemin.

Depuis un nœud, l’administrateur descend vers ses enfants ou remonte au moyen d’un fil construit à partir des vraies relations. La structure visible correspond donc à celle que les validations protègent lors de l’écriture.

Chaque traduction possède une vue et un écran d’édition préparé autour de son adresse publique. La section SEO expose notamment le meta title, ce qui remet les décisions de publication au niveau de la langue concernée.

Le premier lot privilégie la lisibilité du modèle. Il permet de vérifier rapidement qu’une branche, un titre ou un chemin a été créé au bon endroit avant d’ouvrir des opérations éditoriales plus larges.

16. Rendre l’arbre initial reproductible par trois commandes

Langues, utilisateur et nœuds peuvent être rejoués dans un environnement neuf

Trois commandes initialisent le CMS : langues actives, utilisateurs de départ et arborescence. Elles utilisent les cas d’usage du domaine au lieu d’insérer des lignes en contournant les validations.

L’amorçage des nœuds vérifie d’abord la présence du français, de l’anglais et de l’espagnol. Si ces langues manquent, il s’arrête et indique la commande à exécuter, ce qui évite de construire un arbre partiellement localisé.

Lorsqu’une clé existe déjà, le nœud est signalé comme ignoré et l’exécution peut continuer. Relancer la commande ne duplique donc pas l’accueil ni les familles déjà créées.

Cette reproductibilité est utile pour préparer un environnement, valider une migration ou repartir d’un schéma propre. La même liste d’intentions et de chemins ne dépend pas d’une suite d’actions manuelles dans l’interface.

17. Transformer 83 intentions de page en 249 versions localisées

Une première carte du site suffisamment vaste pour éprouver le modèle

L’arbre commence par l’accueil et six branches principales : solutions, produits, formations, ressources, agence et contact. Il ajoute cinq univers de service, trois produits, les actualités, les projets et trois pages d’agence.

Les familles métier détaillent ensuite 22 catégories d’intégration API, 10 services d’agence marketplace, 17 responsabilités de création marketplace, 4 offres de développement web et 10 expertises SEO technique.

Au total, la configuration contient 83 nœuds. Chacun reçoit une version française, anglaise et espagnole, soit 249 traductions initiales avec des chemins construits depuis ceux de leurs parents.

La diversité compte autant que le nombre : certaines branches restent identiques dans les trois langues, d’autres changent de titre et de slug. Le modèle rencontre ainsi dès l’amorçage les cas réels qu’il doit distinguer.

18. Vérifier le trajet complet avec neuf scénarios d’intégration

Du cas d’usage métier jusqu’aux écrans réservés au super-administrateur

Le premier scénario appelle directement le domaine et confirme que le nœud et trois objets de traduction sont produits puis persistés. Le suivant effectue la même création par l’API avec un jeton et relit la relation en base.

Deux scénarios protègent l’unicité : une seconde clé identique reçoit l’erreur attendue ; un chemin français déjà pris est refusé même lorsque les chemins anglais et espagnol sont différents.

L’amorçage est exécuté puis rejoué pour vérifier la hiérarchie et le comportement idempotent. Un autre test retire les langues et confirme que la commande s’arrête avant d’écrire le moindre nœud.

Les derniers parcours contrôlent la redirection d’un visiteur non connecté, l’accès du super-administrateur à l’arbre et à l’édition SEO d’une traduction, puis les premiers espaces vides du back-office. La qualité couvre ainsi les contrats et leur usage visible.

19. Faire évoluer domaine, arborescence et poste de contrôle dans le bon ordre

Du socle du 22 mai au back-office modernisé du 5 août

La première modification structurante crée les contrats d’accès aux données, les demandes, réponses et présentateurs, les règles d’ajout ainsi que les entités Doctrine. Elle donne au CMS une grammaire avant de lui donner une interface HTTP.

Quelques secondes plus tard dans l’historique, la modification suivante ajoute les commandes d’amorçage, la connexion, le renouvellement de jeton et la création de nœud. Les premières vues administratives et leur suite de tests arrivent dans les minutes suivantes : l’extérieur appelle alors un domaine déjà capable de refuser les incohérences.

Entre le 2 et le 30 juin, la définition des nœuds suit les découpages successifs des offres API, marketplace et SEO. L’arbre n’est pas une photographie figée du premier jour : il reste synchronisé avec les familles que le site veut réellement porter.

Le 5 août modernise enfin l’espace d’administration et complète les parcours testés. La séquence démontre une méthode de réduction du risque : valider l’identité multilingue, maintenir la cible de migration puis améliorer le poste de contrôle opérateur sans mélanger ces responsabilités.

20. Les arbitrages qui structurent Dawap CMS

Identité stable, complétude des langues et migration progressive

Premier arbitrage : la clé du nœud ne dépend pas du chemin. Les redirections et changements d’adresse futurs pourront être traités comme des décisions de publication sans casser les relations internes.

Deuxième arbitrage : toutes les langues actives sont requises à la création. Ce choix exige de préparer les trois versions, mais il évite un arbre initial dont certaines branches disparaissent selon la locale sans décision explicite.

Troisième arbitrage : le SEO vit dans la traduction. Une canonique, une directive robots ou une date de sitemap peut ainsi refléter la situation de la version concernée au lieu d’être forcée au niveau global.

Quatrième arbitrage : conserver deux modes de rendu. Les gabarits existants offrent une migration progressive ; le contenu structuré prépare les futures pages composables. Le projet avance sans conditionner la nouvelle arborescence à une réécriture simultanée de tout le front.

21. Ce que la première livraison change concrètement

Une cible de migration explicite au lieu d’une suite de pages indépendantes

Avant ce socle, l’arbre destiné au CMS n’existait pas comme objet unique avec ses contraintes. Après la livraison, 83 intentions possèdent une clé, un type, une place et 249 versions localisées reproductibles.

Une intégration peut créer une page sans choisir elle-même les règles d’unicité, de profondeur ou de complétude linguistique. Les erreurs reviennent avec le champ concerné, ce qui rend un import corrigeable avant qu’il n’altère la structure.

L’équipe peut parcourir les branches, rechercher un chemin et ouvrir les données SEO d’une traduction depuis un espace protégé. Le diagnostic d’une incohérence ne commence plus par une requête manuelle dans la base.

Le projet fournit surtout un ordre de migration sûr : langues, arbre, traductions, puis contenus plus riches. Chaque future fonction rejoint une identité déjà contrôlée au lieu de recréer ses propres conventions.

22. Créer la page « Intégration API » dans trois langues

Une seule intention, trois chemins et les mêmes règles avant écriture

L’outil d’amorçage prépare un nœud `integration-api`, de type solution, enfant de `solutions` en profondeur deux. Le mode Twig lui associe le gabarit de page de service et son statut publié.

La traduction française utilise le titre « Intégration API » et le chemin `solutions/integration-api`. L’anglais choisit « API integration » et `solutions/api-integration`. L’espagnol adopte « Integración API » et `soluciones/integracion-api`.

Avant l’écriture, le domaine vérifie le parent, la profondeur, les trois langues, chaque chemin, chaque slug et l’absence de collision locale. Il prépare ensuite le nœud et ses trois traductions dans la même transaction.

Dans le back-office, une recherche sur la clé, un titre ou l’un des chemins retrouve le même objet. L’administrateur peut descendre depuis Solutions, voir les trois versions et ouvrir la zone SEO de celle qu’il souhaite contrôler.

23. Étendre le produit sans réécrire sa fondation

Édition complète, contenus structurés et migration deviennent des lots identifiables

Le modèle contient déjà des relations destinées aux résumés, blocs de contenu, articles et études de cas. Leur présence dessine les prochains besoins, mais leur parcours d’édition complet devra conserver la même exigence que celui des nœuds.

La suite logique consiste à enrichir les commandes de mise à jour, les médias, la prévisualisation, les transitions de statut et le rendu du contenu structuré. Chaque capacité pourra réutiliser l’identité, les langues et les contrôles SEO existants.

La migration du site peut ensuite progresser branche par branche. Les modes Twig et structuré autorisent une coexistence : une page conserve son gabarit pendant qu’une autre adopte des blocs, sans abandonner l’arbre commun.

Cette approche donne à Dawap un terrain concret pour ses projets de création d’API métier et de sites web sur mesure : commencer par les invariants qui protègent les futures évolutions.