Directus : un CMS headless puissant, mais parfois trop technique

Quand on parle de CMS headless, Directus revient souvent parmi les options les plus sérieuses. Et ce n’est pas un hasard. La plateforme permet de connecter une base SQL, de modéliser ses données visuellement, de générer instantanément des APIs REST et GraphQL, et de gérer des permissions très fines via son Data Studio. Directus se présente d’ailleurs moins comme un simple CMS que comme un backend flexible pour des projets data-driven, avec une couche d’administration complète au-dessus des données.

Sur le plan technique, c’est un outil particulièrement séduisant. Pour une équipe produit, une équipe technique ou une agence qui veut construire un socle robuste, Directus coche beaucoup de cases : structure claire, gouvernance des accès, logique API-first, compatibilité avec des stacks modernes, et capacité à alimenter un site, une application ou plusieurs interfaces à partir d’une même source de vérité. C’est précisément ce qui explique pourquoi il génère autant d’intérêt chez les entreprises qui veulent sortir d’un CMS monolithique ou trop rigide.

Mais une question revient souvent une fois le projet lancé : Directus est-il aussi agréable à utiliser pour les équipes non-tech qu’il est agréable à mettre en place pour les développeurs ?

C’est là que le sujet devient plus intéressant. Car dans beaucoup de projets, le vrai enjeu n’est pas seulement de choisir un bon backend. Le vrai enjeu, c’est de livrer une interface que les équipes métier, marketing, contenu ou opérationnelles vont réellement comprendre, adopter et utiliser sans friction au quotidien.

Et c’est précisément sur ce point que Directus, malgré toutes ses qualités, peut parfois montrer ses limites.
‍

Pourquoi Directus plaît autant aux développeurs et aux équipes produit

Avant de parler de ses limites, il faut être clair : si Directus est autant adopté, c’est parce qu’il apporte une vraie valeur.

D’abord, il permet de travailler à partir d’une base de données SQL avec une logique beaucoup plus structurée qu’un CMS classique orienté “pages”. On définit des collections, des champs, des relations, des permissions, puis on expose le tout via des APIs documentées. Cette approche est extrêmement intéressante dès qu’un projet dépasse la simple publication de contenus marketing et commence à manipuler des objets métiers, des référentiels, des catalogues, des workflows ou des données partagées entre plusieurs interfaces.

Ensuite, Directus propose une gouvernance des accès particulièrement fine. Les permissions et policies permettent de contrôler ce que chaque rôle peut voir, créer, modifier, supprimer ou partager. Dans les environnements où plusieurs profils interviennent sur les données, c’est un avantage majeur. On ne parle pas seulement de publier des contenus, mais de sécuriser l’accès à des informations parfois sensibles, avec des règles adaptées à chaque usage.

Autre point fort : l’extensibilité. Directus permet d’aller au-delà du standard via des extensions d’interface, de modules, de layouts, de panels ou d’affichages dans son Data Studio. Sur le papier, cela ouvre énormément de possibilités pour adapter l’outil à un contexte métier spécifique. Cette capacité est réelle, et c’est aussi pour cela que Directus séduit les profils techniques qui veulent une base solide mais non fermée.

En résumé, Directus n’est pas “juste” un CMS. C’est un très bon moteur de contenu et de données, avec une logique backend moderne. Et pour beaucoup de projets, c’est exactement ce qu’il faut.
‍

Là où la promesse se heurte parfois à la réalité terrain

Le problème commence rarement au moment du cadrage technique. Il apparaît plus souvent après la mise en ligne, quand le client ou l’équipe non-tech commence à utiliser l’outil au quotidien.

Sur le papier, le Data Studio de Directus est propre, clair et structuré. Dans la pratique, son ergonomie reste fortement liée à la logique de données sous-jacente. Et c’est là que tout se joue : une interface pensée à partir d’un modèle relationnel, même bien conçue, n’est pas forcément intuitive pour un profil qui raisonne en pages, en blocs, en campagnes, en fiches ou en actions métier.

Autrement dit, ce qui est naturel pour un développeur ou un product builder ne l’est pas forcément pour un chargé de contenu, un responsable marketing, un commercial ou un client final.

Cette friction n’est pas qu’une impression isolée. On la retrouve dans les avis publics. Sur G2, un utilisateur explique que la majorité des retours de ses utilisateurs internes concerne l’interface d’édition, jugée parfois “clunky”, notamment lorsqu’il faut éditer des collections enfants dans un side drawer ou comprendre les relations entre collections, ce qui peut faire perdre le fil dans la hiérarchie des composants.

Ce retour est intéressant parce qu’il ne remet pas en cause la puissance de Directus. Il pointe quelque chose de plus subtil, mais de plus important en contexte réel : la charge cognitive de l’édition.

Tant que le modèle est simple, tout va bien. Mais dès qu’on entre dans un projet avec plusieurs collections liées entre elles, des composants imbriqués, des niveaux de relation, des validations métier ou des parcours spécifiques par rôle, l’interface peut devenir plus difficile à appréhender pour des utilisateurs non-tech. Le problème n’est pas l’absence de fonctionnalités. Le problème, c’est le décalage entre la structure technique et l’expérience d’usage.
‍

Le vrai sujet : un excellent back-office n’est pas toujours une excellente interface métier

C’est souvent ici que les projets se trompent de diagnostic.

On entend parfois : “Le client n’a pas été assez formé.”
Ou : “Il faut juste prévoir un onboarding plus poussé.”

Bien sûr, la formation aide. Mais elle ne résout pas tout. Quand une interface demande aux utilisateurs de comprendre une logique de données qui ne correspond pas à leur manière de travailler, le problème n’est pas seulement pédagogique. Il est aussi produit.

Une bonne interface métier ne devrait pas demander à un utilisateur de penser comme l’architecte de la base de données. Elle devrait lui permettre de faire son travail avec le minimum de friction possible.

C’est pour cela qu’un outil peut être excellent techniquement et pourtant imparfait dans un contexte client. Directus est très performant lorsqu’on veut centraliser, structurer, sécuriser et exposer des données. En revanche, dès que l’enjeu principal devient l’adoption par des profils non-tech, la question n’est plus uniquement “est-ce que Directus sait le faire ?”, mais “est-ce que l’interface native est la meilleure manière de le faire ?”.

Dans beaucoup de cas, la réponse est : pas complètement.
‍

Oui, Directus est personnalisable… mais pas sans coût

Il serait faux de dire que Directus ne permet pas d’adapter son interface. Au contraire, la plateforme met en avant une logique très extensible, avec des app extensions chargées dans le Data Studio et construites en Vue 3, en JavaScript ou TypeScript, à l’aide du SDK Directus. Le codebase overview officiel rappelle aussi que le Data Studio lui-même est écrit en Vue.js 3.

Mais c’est précisément là que se situe la nuance importante.

La personnalisation existe, oui. En revanche, lorsqu’on veut aller vers une vraie interface sur mesure pour un client ou une équipe métier, on sort vite du simple paramétrage. On entre dans une logique de développement spécifique : réflexion UX, conception d’écrans, création de composants, gestion des cas métiers, maintenance, compatibilité avec les évolutions du projet, etc.

Autrement dit, la personnalisation avancée de l’expérience d’édition a un coût réel.

Ce besoin n’est pas nouveau. Il existe depuis longtemps dans l’écosystème Directus. Une issue GitHub ancienne demandait déjà comment afficher une interface custom uniquement pour des clients tout en conservant l’interface standard pour l’admin. Le sujet n’est donc pas un edge case inventé par quelques agences : c’est un besoin récurrent dès qu’on livre Directus à des utilisateurs finaux aux usages très différents de ceux des développeurs.

C’est là que beaucoup de projets perdent du temps. Ils partent sur Directus pour sa rapidité de mise en place, puis découvrent que rendre l’expérience parfaitement adaptée à des non-tech demande un effort bien supérieur à ce qui avait été anticipé.
‍

{{cta}}
‍

Là où les équipes non-tech décrochent vraiment

Dans les projets que nous voyons passer, les points de friction sont rarement “techniques” au sens strict. Ils sont surtout liés à l’usage quotidien.

Par exemple :

Une équipe marketing ne veut pas “gérer une collection avec des relations”. Elle veut mettre à jour une page campagne sans se demander dans quelle hiérarchie de contenu elle se trouve.

Une équipe commerciale ne veut pas naviguer dans plusieurs vues ou comprendre la différence entre un item parent et des sous-éléments liés. Elle veut retrouver rapidement la bonne fiche, modifier les bonnes informations, et être sûre de ne rien casser.

Un client final ne veut pas voir un back-office générique avec toutes les options possibles. Il veut une interface épurée, limitée à son périmètre, qui parle son langage métier.

C’est pour cela que la limite de Directus n’est pas forcément sa puissance, mais son point de départ : l’outil part de la donnée. Or certains utilisateurs, eux, partent de l’action.

Et cette différence change tout.
‍

Directus seul est souvent un bon choix… jusqu’à ce que l’adoption devienne la priorité

Il faut le dire franchement : dans beaucoup de cas, Directus seul suffit largement.

Si votre équipe est à l’aise avec les concepts de collections, de champs, de relations et de rôles, l’interface native fait très bien le travail. Si vous avez des profils produit ou ops qui manipulent déjà des outils structurés, l’apprentissage peut être rapide. Et si votre objectif principal est d’avoir un backend flexible, bien gouverné et interopérable, Directus reste une option très solide.

Mais dès que l’adoption par des non-tech devient un critère clé, il faut changer de grille de lecture.

La question n’est plus seulement : “Est-ce que le système fonctionne ?”
La vraie question devient : “Est-ce que les utilisateurs vont l’utiliser avec fluidité, autonomie et confiance ?”

À ce moment-là, il devient pertinent de dissocier deux couches :

• Directus comme moteur de données, de permissions et d’API
  
  
• une interface sur mesure comme couche d’usage métier
  
  

Et cette distinction change profondément la qualité du produit livré.
‍

Notre conviction chez Scroll : garder Directus comme moteur, construire un front pensé pour les utilisateurs

C’est l’approche que nous défendons sur les projets où Directus est pertinent techniquement, mais où l’interface native n’est pas la meilleure réponse côté usage.

Plutôt que de forcer les équipes métier à rentrer dans la logique du back-office, nous préférons conserver Directus pour ce qu’il fait très bien — structurer, centraliser, gouverner et exposer les données — puis construire un front adapté au niveau de maturité et aux besoins des utilisateurs finaux.

Concrètement, cela permet de simplifier radicalement l’expérience.

L’utilisateur ne voit plus une interface générique. Il voit uniquement les actions qu’il doit réellement effectuer.

Les formulaires ne reflètent plus toute la complexité du modèle de données. Ils reflètent un parcours métier clair.

Les écrans peuvent reprendre le vocabulaire du client, masquer les éléments inutiles, regrouper certaines étapes, guider l’utilisateur, limiter les risques d’erreur et accélérer la prise en main.

En coulisses, Directus continue pourtant à jouer son rôle de socle. Les données restent structurées. Les permissions restent maîtrisées. Les APIs restent disponibles pour les autres briques du système. Le projet conserve donc les avantages d’un backend moderne sans imposer sa logique native à tous les utilisateurs.

C’est, à notre sens, le meilleur des deux mondes.
‍

Dans quels cas faut-il envisager un front sur mesure au-dessus de Directus ?

Tous les projets n’en ont pas besoin. Mais certains signaux doivent alerter.

Premier signal : le client est peu technique et doit intervenir régulièrement dans l’outil.

Deuxième signal : le modèle de données comporte plusieurs relations, sous-collections, contenus imbriqués ou règles métier.

Troisième signal : plusieurs profils différents doivent utiliser l’interface, avec des attentes très distinctes.

Quatrième signal : l’outil doit ressembler davantage à un logiciel métier qu’à un CMS ou un back-office générique.

Cinquième signal : l’enjeu principal n’est pas seulement d’administrer des données, mais de garantir l’autonomie des utilisateurs et la qualité opérationnelle dans le temps.

Dans ces situations, il est souvent plus rentable de penser l’interface dès le départ plutôt que d’empiler des contournements ou de compenser les frictions par de la formation continue.
‍

Directus seul ou Directus avec front custom : comment choisir ?

On peut résumer le choix très simplement.

Directus seul est souvent le bon choix si :

• les utilisateurs sont à l’aise avec des outils structurés,
  
  
• la complexité du modèle reste raisonnable,
  
  
• l’équipe interne a une culture produit ou technique,
  
  
• le besoin principal est de centraliser et gouverner des données.
  
  

Directus + front sur mesure devient souvent préférable si :

• les utilisateurs finaux sont non-tech,
  
  
• la simplicité d’usage est un enjeu business,
  
  
• le projet comporte une vraie logique métier,
  
  
• l’interface doit masquer la complexité du modèle,
  
  
• l’adoption et l’autonomie sont des critères aussi importants que l’architecture.
  
  

Le point clé, c’est qu’il ne faut pas choisir entre “Directus” et “pas Directus”. Il faut choisir comment Directus doit être utilisé dans votre architecture.

Et c’est une différence essentielle.
‍

Directus est souvent un très bon choix technique, mais l’expérience utilisateur ne doit pas être une variable secondaire

Directus mérite clairement sa place parmi les outils les plus intéressants du marché pour structurer et exposer des données. Son approche API-first, sa couche d’administration, ses permissions fines et son extensibilité en font un excellent socle pour de nombreux projets.

Mais dans un projet réel, la réussite ne dépend pas uniquement de la qualité du backend. Elle dépend aussi de la capacité des utilisateurs finaux à travailler vite, bien et sereinement dans l’outil qu’on leur met entre les mains.

C’est là qu’il faut être lucide : un excellent moteur de contenu n’est pas toujours une excellente interface métier.

Chez Scroll, c’est précisément pour cela que nous ne regardons pas seulement la performance technique d’un stack. Nous regardons aussi la qualité d’usage qu’il permettra demain. Quand Directus est le bon socle, nous le gardons. Mais lorsque l’interface native devient une source de friction pour des profils non-tech, nous préférons construire un front plus simple, plus clair et plus aligné avec les vrais usages.

Parce qu’au fond, un outil n’est pas réussi quand il est seulement bien conçu côté dev. Il est réussi quand les personnes qui doivent l’utiliser au quotidien ont réellement envie de s’en servir.