Étude de cas · produit digital
altaydagistan.com
Concevoir une plateforme digitale complète, de l’interface au système
Une expérience publique et son environnement de publication, pensés comme un seul produit.
010203hero-cms-general-uiReconstruire le site ne consistait pas seulement à changer de technologie. L’objectif était de relier une direction artistique exigeante, une publication fluide, des outils de conversion, des contenus multilingues et une architecture technique maîtrisée.
J’ai conçu l’interface publique, le CMS sur mesure et les liens entre les deux. Le résultat est un système capable d’accueillir des projets visuellement singuliers sans enfermer leur présentation dans un gabarit rigide.
01 / Intention
Partir de l’expérience, pas de l’outil
Le projet commence avec deux utilisateurs et deux rythmes très différents : une personne qui découvre le travail, et une autre qui maintient un site complexe dans la durée.
Ce cadrage permet d’évaluer chaque décision technique par son effet sur la clarté, la liberté visuelle, la vitesse de publication et la maîtrise à long terme.
- 01Un frontend singulier
Grandes images, mouvement et compositions éditoriales variées restent possibles.
- 02Un CMS utilisable
Les modèles et les actions suivent le vrai travail de publication.
- 03Une conversion utile
Formulaires, ressources protégées et prises de contact font partie du produit.
- 04Un système maîtrisé
Langues, SEO, mesure, contexte IA et déploiements partagent une architecture.
02 / Direction artistique
Garder la direction artistique visible dans le produit final
Le frontend n’est pas une enveloppe neutre autour du contenu du CMS. Il porte un rythme, une typographie et un langage de mouvement reconnaissables, tout en laissant leur place à des projets aux identités très différentes.
Les mêmes règles passent de Figma aux composants Astro et aux comportements responsives. Elles assurent la hiérarchie et la continuité sans transformer toutes les pages en cartes interchangeables.
- 01Hiérarchie
Un ordre de lecture stable sur les pages éditoriales et commerciales.
- 02Composition
Des mises en page adaptées au contenu et au ratio naturel des images.
- 03Mouvement
Des transitions discrètes qui clarifient la séquence sans masquer le travail.
Trois projets, trois registres visuels
Le système visuel conserve des repères de lecture communs tout en laissant à chaque projet sa densité, sa palette et sa logique d’image.
Cocolabs
Produit digital et interface
HugoDécrypte
Récit éditorial
SISU
Pitch deck et narration visuelle
03 / Produit éditorial
Dessiner le CMS comme une interface de travail
L’administration est un produit à part entière. La navigation, les modèles de contenu, les états et les actions sont organisés autour des tâches fréquentes, pas autour d’un empilement de plugins.
Un projet peut réunir métadonnées, médias ordonnés, traductions, champs SEO et contenus spécifiques sans se réduire à un éditeur de texte générique.
special_pagePubliéservicePubliéspecial_page Protégécms-admin-wideUne administration dense mais lisible, conçue pour la publication quotidienne.
cms-project-editorÉditeur structuréLes champs et les relations suivent la forme réelle d’un projet portfolio.
Voir+ Traduirecms-translation-coverageCouverture des traductionsLe français et l’anglais restent liés à une même entité de contenu.
- 01Modéliser
Pages, projets, articles et formulaires disposent de structures explicites.
- 02Publier
États, ordre, traductions et visibilité peuvent être contrôlés rapidement.
- 03Étendre
De nouveaux champs et templates s’ajoutent sans reconstruire le produit.
04 / Architecture
Deux applications, un seul produit
Le CMS gère et expose un contenu structuré. Astro compose et génère le site public. Chaque côté conserve le rythme et les responsabilités qui lui correspondent.
- 01Administrer
CMS sur mesure
- 02Structurer
API de contenu
- 03Composer
Frontend Astro
- 04Diffuser
Site public statique
Pages rapides, images responsives, mouvement et interactions sont livrés sans dépendre du CMS à l’exécution.
Contenus, traductions, demandes, ressources protégées et contrôles de publication restent dans une interface spécialisée.
Demandes de devis, prises de contact et téléchargements sécurisés sont intégrés au produit.
Métadonnées, URL canoniques, données structurées et indexation font partie de la publication.
Les actions utiles peuvent être lues comme un parcours plutôt que comme un simple volume de visites.
Contenus et code peuvent évoluer séparément sans perdre leur structure commune.
05 / IA intégrée
Intégrer les agents IA directement au workflow
L’IA fait partie de l’environnement de travail de la plateforme plutôt que d’intervenir ponctuellement en fin de chaîne.
/ai/site-context.jsonContenus publiés uniquement.ai/site-context.jsonBrouillons et identifiants internes/llms.txtCarte lisible du site{"site": { "defaultLocale": "fr" },"pages": [{ "slug": "services","status": "published","locales": { "fr": true, "en": true } }],"portfolio": [ … ]}cms-ai-contextLa vue AI Context mise en œuvre sépare les données de travail privées, l’index public assaini et le fichier de découverte.
Un contexte privé pour le travail local
Le CMS maintient automatiquement un contexte structuré destiné aux agents utilisés en local. Il décrit l’état réel du site : pages, projets, routes, langues, statuts de publication, traductions et présence des principales informations SEO.
Le fichier .ai/site-context.json constitue l’index de référence pour Claude, Codex et les autres agents connectés au projet. Il leur permet de comprendre immédiatement la structure éditoriale du site et de croiser cette information avec le code, les composants et les instructions propres au projet.
PromptQuelles pages restent à traduire ?
PromptQuels contenus n’ont pas encore de meta description ?
PromptQuelle est la structure actuelle du portfolio ?
PromptQuelles routes doivent être prises en compte avant de modifier la navigation ?
Cette approche réduit les échanges de contexte manuels et permet d’intégrer l’IA directement aux workflows de conception, de développement et de maintenance.
Une exposition publique maîtrisée
Le contexte utilisé en local reste distinct de ce qui est rendu accessible sur le site public.
Au moment du build, Astro génère une version assainie de l’index dans /ai/site-context.json, ainsi qu’un fichier llms.txt destiné à fournir une carte concise du site aux systèmes compatibles. Les brouillons, identifiants internes et métadonnées d’administration restent exclus de cette version publique.
Pages, projets, langues, statuts et informations SEO suivent une structure prévisible et directement exploitable par machine.
Les agents travaillent sur le projet depuis l’environnement local, avec accès au code, aux instructions du projet et à un état actualisé du CMS.
Les changements effectués dans le CMS actualisent le contexte privé. Le déploiement reconstruit ensuite les fichiers publics à partir de la source courante.
Les informations destinées au développement restent privées tandis que l’export public contient uniquement les données nécessaires à la compréhension du site publié.
Cette architecture transforme l’IA en une couche native du produit : les agents disposent du contexte dont ils ont besoin pour comprendre le système, intervenir avec davantage de précision et accompagner son évolution sans dépendre d’exports ou d’explications répétées. La mise à disposition de ces données facilite leur exploitation par les outils compatibles ; elle ne garantit toutefois ni leur utilisation, ni leur citation ou leur classement par un service d’IA.
06 / Qualité
Traiter la performance et la robustesse comme des critères de design
La génération statique, les formats d’image responsifs, les polices auto-hébergées et les dépendances navigateur limitées protègent l’expérience au lieu d’être ajoutés en fin de projet.
Les champs de publication produisent les sorties canoniques, sociales et structurées attendues par le frontend.
Sessions sécurisées, protection CSRF, requêtes préparées, limites de débit et accès contrôlés restent derrière l’interface.
Checkpoints du code, sauvegardes de la base et publications explicites préservent des points de retour.
07 / Évolution
Rendre le changement explicite et récupérable
La plateforme est conçue pour un travail continu. Le contenu et le code évoluent indépendamment, tandis que les changements sensibles suivent une séquence de publication courte et visible.
- 01Checkpoint
Conserver l’état actuel du code
- 02Sauvegarder
Protéger les contenus et les données
- 03Vérifier
Construire et contrôler le site public
- 04Publier
Mettre en ligne par une décision explicite
Conclusion
Une plateforme pensée pour évoluer
Le résultat principal n’est ni le CMS ni le frontend pris séparément. C’est l’environnement qui les relie : assez structuré pour rester fiable, assez ouvert pour accueillir des besoins éditoriaux et artistiques changeants.
Le site n’est plus seulement l’endroit où le travail est présenté. Il devient un produit qui démontre le même niveau de jugement graphique, de maîtrise technique et d’attention à l’usage proposé aux clients.
Parler d’un projet digital