Personnalisation extrême de Strapi 5 : Intégration de Quill et architecture multi-tenant
blog AI Technology

Personnalisation extrême de Strapi 5 : Intégration de Quill et architecture multi-tenant

Strapi 5 is an excellent headless CMS, but I customized it heavily for kuro.boo, replacing Lexical with Quill and adding database schema-based multi-tenancy.


En septembre 2025, la sortie de « Strapi 5 » a apporté des mises à jour majeures pour les développeurs. Rompant nettement avec les structures de données de Strapi 4, cette version a introduit des changements majeurs, repensé les API multilingues et boosté les performances. Bien qu'il soit devenu un outil plus simple et plus puissant, certaines configurations par défaut laissaient place à des améliorations.

Plus précisément, l'éditeur par défaut « Blocks » (basé sur Lexical) est moderne mais manque d'outils avancés pour l'édition de tableaux et la mise en forme de texte, souvent nécessaires pour des mises en page riches. Il ne permettait même pas de créer un tableau simple par défaut. Bien que les bordures de tableau soient moins courantes dans les designs occidentaux, elles sont essentielles au Japon pour créer des pages structurées et faciles à lire.

De plus, Strapi 5 ne gère pas nativement le multi-tenancy. Bien qu'il soit possible de lancer des conteneurs séparés pour chaque organisation, exécuter une base de données PostgreSQL dédiée pour chaque client s'avère coûteux. Pour parvenir à un multi-tenancy économique, j'ai personnalisé le backend. Voici comment j'ai modifié l'environnement Strapi 5 pour le blog « kuro.boo » afin d'obtenir une excellente expérience d'édition et une grande efficacité de gestion.


1. Résolution des bugs de saisie en japonais (IME)

Strapi est construit sur React, lo que induit certains comportements de l'interface utilisateur. L'éditeur principal de Strapi 5 présentait des problèmes mineurs lors du traitement des événements IME en japonais, provoquant des sauts de curseur lors de la frappe. J'ai essayé trois IME différents sur macOS (celui par défaut d'Apple, Google Japanese Input et Kawasemi), mais les problèmes de curseur persistaient car l'éditeur interceptait des événements de touches inutiles. Au départ, je devais rédiger mes articles dans des éditeurs externes comme Zed, puis les copier-coller. C'était bien trop fastidieux.


2. Gestion de plusieurs images

Les articles nécessitent plus que du simple texte et des images de couverture. J'ai d'abord testé le plugin suivant :


TipTap


TipTap est populaire et prend en charge plusieurs images, mais son implémentation nécessitait d'ajouter des blocs de saisie distincts pour chaque image et chaque paragraphe de texte. Cela semblait dépassé et loin d'une véritable expérience WYSIWYG, me faisant regretter la fluidité des outils de Dropbox Paper (que j'utilise fréquemment).

3. Transition vers Quill

Puisque Lexical et TipTap ne répondaient pas à mes besoins, je me suis tourné vers Quill. Avec sa version v2, Quill offre une excellente flexibilité. Ses fonctionnalités WYSIWYG semblaient prometteuses, mais il manquait encore d'un support natif pour les tableaux complexes. Pour y remédier, j'ai intégré « quill-better-table » (après une journée de débogage). Ce plugin permet d'ajouter/supprimer des lignes et des colonnes via un clic droit, de fusionner des cellules et de personnaliser le style des cellules directement depuis le panneau d'administration de Strapi. Surtout, ces tableaux sont enregistrés au format HTML standard, ce qui les rend faciles à restituer dans le frontend Astro.

Cela a résolu à la fois l'édition des tableaux et les problèmes de saisie IME, nous offrant un panneau d'édition WYSIWYG hautement fonctionnel dans Strapi :


4. Ajout du téléversement d'images par glisser-déposer

Pour fluidifier l'écriture, j'ai ajouté une fonction glisser-déposer : faire glisser une image ou la coller depuis le presse-papiers déclenche automatiquement l'API d'upload de Strapi, l'enregistre dans la bibliothèque multimédia et l'insère dans l'éditeur. (Note : comme le glisser-déposer n'affiche pas de messages d'erreur détaillés pour les fichiers trop volumineux, nous devons toujours surveiller les limites de taille de fichier).

5. Multi-tenancy basé sur les schémas

Pour gérer plusieurs sites sur une seule instance Strapi sans déployer des conteneurs de base de données séparés, j'ai implémenté le changement de schéma de base de données (DATABASE_SCHEMA) au sein de la même instance de base de données. Cela permet de limiter les coûts de base de données tout en maintenant des environnements isolés et sécurisés pour chaque client.


6. Un flux de travail basé sur le local pour la génération de sites statiques (SSG)

Bien que l'exécution d'un serveur CMS 24h/24 et 7j/7 soit idéale pour les équipes collaboratives, elle engendre des coûts inutiles et des risques de sécurité pour les blogs personnels ou les sites à faible fréquence de mise à jour. Par conséquent, j'ai modifié l'architecture de déploiement :

  1. Lancez l'instance Strapi locale uniquement lors de la rédaction ou de la modification.
  2. Lancez un build de développement qui compile le contenu Strapi en pages statiques Astro, copie les images dans le dossier de build et met à jour les liens d'images.
  3. Arrêtez l'instance Strapi locale et déployez le site entièrement statique sur Cloudflare Pages.


Cette configuration signifie que notre site public est entièrement hébergé sur le réseau de diffusion de contenu (edge) de Cloudflare. Il se charge extrêmement rapidement, ne coûte rien à héberger et élimine les risques de sécurité liés aux bases de données publiques. Pour kuro.boo, je laisse tourner l'instance Strapi locale sur ma machine par commodité, car cela n'entraîne aucuns frais d'hébergement.

Comparaison des configurations par défaut et personnalisées :

Fonctionnalité

Configuration par défaut

Personnalisation kuro.boo

Cœur de l'éditeur

Lexical (Blocks)

Quill (v2+)

Édition de tableaux

Limitée

quill-table-better (Prend en charge la fusion et le style des cellules)

Hébergement (Tenancy)

Une seule base / un seul schéma

Multi-tenancy basé sur les schémas

Traitement des images

Téléversement manuel

Upload automatique des médias par glisser-déposer ou coller

Zone dynamique

Sélecteur standard

Panneau intégré pour l'upload d'images par lot

Architecture

CMS toujours actif

CMS local uniquement avec génération de site statique (SSG)

Build/Déploiement

Manuel / Webhook simple

Déploiement automatisé via GitHub Actions

Conclusion

J'ai également résolu un petit bug où toute modification mineure mettait à jour la date de publication de l'article, ce qui poussait les anciens articles en tête de flux. J'ai ajouté un champ dédié `publishedAt` et trié par ce champ. Bien que la modification directe du code source de Strapi 5 puisse compliquer les futures mises à niveau, ce niveau de personnalisation est ce qui fait la force des plateformes CMS headless. Cela m'a permis de concevoir un environnement d'édition parfaitement adapté à mes besoins.

Sources :

Documentation de Strapi 5

Quill - Éditeur de texte enrichi

quill-table-better (GitHub)