TipTap dans React Native : editeur rich text mobile

Un memo, ce n'est pas juste du texte brut. C'est une idee structuree : des titres, du gras, des listes a puces, des blocs de code... et surtout des checklists interactives. Dans une app collaborative comme TAMSIV, une checklist devient un veritable outil de coordination d'equipe. Le probleme ? Integrer un editeur rich text complet dans une app React Native, c'est un defi technique que peu de developpeurs abordent de front.

J'ai passe trois semaines a construire cet editeur. Trois semaines de bugs WebView, de galeres de clavier mobile et de synchronisation temps reel. Voici tout ce que j'ai appris.

Points cles a retenir :
- TipTap fonctionne dans React Native via une WebView avec un bridge bidirectionnel JSON
- Les checklists collaboratives necessitent deux modes : validation "single" et "everyone"
- La synchronisation se fait au niveau des items individuels, pas du document entier
- Le clavier mobile est le plus gros defi technique de l'integration
- Supabase Realtime permet une synchronisation temps reel sans CRDT complexe

Pourquoi un editeur rich text dans une app mobile ?

La reponse courte : parce que le texte brut ne suffit pas. Quand tu prends un memo en reunion, tu veux mettre un titre, souligner une idee importante, creer une liste d'actions. Un champ TextInput basique ne permet rien de tout ca.

J'ai evalue plusieurs options avant de me lancer. Le constat etait simple : les apps de productivite qui reussissent en 2026 — Notion, Obsidian, Craft — proposent toutes un editeur riche. C'est devenu un standard. Un memo vocal qui se transforme en texte brut, ca fait date.

Dans TAMSIV, l'editeur rich text sert principalement dans les memos — ces notes longues que tu dictes vocalement et que tu veux ensuite enrichir manuellement. Le pipeline vocal genere du texte structure, et l'editeur permet de l'ajuster.

Comment fonctionne TipTap dans React Native ?

TipTap est un editeur fantastique sur le web. Il est base sur ProseMirror, extensible, bien documente, et la communaute est active. Le probleme : React Native n'a pas de DOM. TipTap ne peut pas fonctionner nativement.

La solution que j'ai retenue : une WebView qui embarque l'editeur TipTap complet. L'architecture se decompose ainsi :

• Cote WebView : TipTap s'execute dans un environnement web classique, avec toute sa puissance
• Bridge bidirectionnel : les messages passent entre React Native et la WebView via postMessage / onMessage
• Serialisation JSON : le contenu de l'editeur est serialise en JSON TipTap, envoye au bridge, puis stocke en HTML en base de donnees

Ce pattern n'est pas ideal — il ajoute une couche de complexite — mais c'est le seul qui permette d'avoir un editeur riche complet sur mobile sans reecrire ProseMirror from scratch.

Quelles fonctionnalites l'editeur supporte-t-il ?

L'editeur TAMSIV supporte un ensemble complet de formatage :

• Titres (H1, H2, H3) pour structurer les memos longs
• Gras et italique pour l'emphase
• Listes a puces et numerotees
• Blocs de code pour les developpeurs (oui, meme dans une app de productivite)
• Checklists interactives — le coeur du systeme collaboratif

Le choix a ete delibere : pas de tableaux, pas d'embeds, pas de formules. Chaque fonctionnalite ajoutee complexifie le bridge WebView et augmente le risque de bugs. J'ai opte pour un editeur puissant mais focalise.

Le clavier mobile est-il le plus gros defi technique ?

Oui, sans aucun doute. Et si tu as deja developpe avec des WebViews sur mobile, tu sais de quoi je parle.

Le probleme fondamental : quand l'utilisateur tape dans la WebView, le clavier natif du smartphone s'ouvre. Mais la WebView n'est pas un composant natif — elle ne communique pas naturellement avec le systeme de gestion du clavier d'Android ou iOS. Resultat :

• Le curseur disparait sous le clavier
• Le scroll automatique ne suit pas la saisie
• Le redimensionnement de la vue est incorrect
• Sur certains appareils Android, le clavier se ferme et se rouvre de facon aleatoire

La solution a necessite du code specifique par plateforme. Sur Android, j'ecoute les evenements resize dans la WebView et j'ajuste manuellement la hauteur. Sur iOS, c'est un peu plus previsible grace a KeyboardAvoidingView, mais il faut quand meme gerer le scroll du curseur manuellement.

J'ai passe presque une semaine entiere uniquement sur les problemes de clavier. C'est le genre de sujet invisible pour l'utilisateur final — quand ca marche, personne ne le remarque — mais qui peut ruiner l'experience si c'est mal gere.

Comment fonctionnent les checklists collaboratives ?

Les checklists, c'est le coeur de la valeur collaborative de TAMSIV. Une liste de courses partagee, un CR de reunion avec des actions, un protocole d'equipe — tous ces cas d'usage reposent sur des checklists. Mais une checklist collaborative, ca ne fonctionne pas comme une checklist personnelle.

J'ai implemente deux modes de validation :

Mode "Single" : un seul suffit

Cas d'usage : "Acheter le cafe". Le premier membre de l'equipe qui le fait coche l'item. C'est fini. Inutile que tout le monde confirme — une seule personne suffit.

En base de donnees, c'est simple : un boolean is_checked et un checked_by (UUID de l'utilisateur). Le premier qui coche "gagne".

Mode "Everyone" : tout le monde doit valider

Cas d'usage : "Lire le compte-rendu de reunion". On veut s'assurer que chaque membre de l'equipe a lu et confirme. L'item n'est "fait" que quand 100% des membres ont coche.

En base, c'est plus complexe : une table de validation stocke l'etat par utilisateur et par item. Chaque coche est independante. L'UI affiche une jauge de progression ("3/5 ont valide") et colore l'item differemment selon le statut.

Ce systeme de double validation est inspire de ce que font les outils professionnels comme Jira ou Monday.com, mais adapte a un usage plus leger — groupes familiaux, petites equipes, associations.

Comment se fait la synchronisation en temps reel ?

La synchronisation est le dernier morceau du puzzle. Quand deux personnes editent le meme memo ou cochent des items en meme temps, il faut que tout reste coherent.

J'utilise Supabase Realtime pour propager les changements. Le choix technique important : la synchronisation se fait au niveau des items individuels, pas du document entier. Quand tu coches un item, seul cet item est mis a jour et propage — pas tout le memo.

Pourquoi ce choix ? Parce que synchroniser un document entier cree des conflits de merge impossibles a resoudre sans un systeme de type CRDT (Conflict-free Replicated Data Types). Les CRDT, c'est elegant en theorie, mais ca ajoute une complexite enorme pour un cas d'usage qui ne le necessite pas.

Le flow de synchronisation :

1. L'utilisateur coche un item dans la WebView
2. Le bridge envoie le changement a React Native
3. React Native ecrit dans Supabase via le service dedie
4. Supabase Realtime propage le changement a tous les abonnes
5. Les autres clients recoivent l'update et mettent a jour leur WebView

Latence typique : 200 a 500ms. C'est pas du Google Docs, mais c'est largement suffisant pour des checklists et des memos collaboratifs. L'important, c'est que les changements ne soient jamais perdus.

Quels sont les pieges a eviter avec TipTap sur mobile ?

Apres trois semaines d'integration, voici les pieges que j'aurais aime connaitre avant de commencer :

1. La taille du bundle WebView. TipTap avec toutes ses extensions pese lourd. J'ai du etre selectif sur les extensions importees. Chaque extension non utilisee ajoutait du poids au chargement initial de la WebView.

2. Le temps de chargement initial. La premiere ouverture de l'editeur est lente (~300ms) parce que la WebView doit charger, parser le HTML, initialiser TipTap. J'ai ajoute un skeleton loader pour masquer ce delai.

3. La gestion memoire. Les WebViews consomment beaucoup de memoire. Sur des appareils d'entree de gamme (Android Go par exemple), ca peut poser probleme. J'ai implemente un systeme de lazy loading qui ne charge la WebView que quand l'utilisateur ouvre effectivement l'editeur.

4. Les raccourcis clavier. Sur tablette avec clavier externe, les utilisateurs s'attendent a Ctrl+B pour le gras, Ctrl+I pour l'italique. Ces raccourcis fonctionnent nativement dans la WebView TipTap, mais il faut s'assurer qu'ils ne sont pas captures par React Native avant d'atteindre la WebView.

5. Le copier-coller. Le contenu copie depuis l'editeur doit etre correctement formate en tant que texte riche ET texte brut. TipTap gere ca nativement, mais le bridge WebView peut parfois casser le formatting.

Comment le pipeline vocal s'integre-t-il avec l'editeur ?

C'est la ou tout se connecte. Le pipeline vocal de TAMSIV permet de dicter un memo par la voix. L'IA transcrit, structure, et genere du texte formate. Ce texte arrive dans l'editeur TipTap deja structure — avec des titres, des listes, parfois meme des checklists pre-remplies.

L'utilisateur peut ensuite modifier le contenu manuellement : ajouter une checklist, reformater un paragraphe, inserer un bloc de code. C'est la combinaison voix + editeur riche qui rend TAMSIV unique. La voix pour la capture rapide, l'editeur pour le peaufinage.

Ce pattern rejoint ce que j'explique dans l'article sur le dictaphone vocal : la voix est un outil de capture, pas un outil d'edition. L'editeur rich text comble exactement ce gap.

Quelles alternatives a TipTap existent pour React Native ?

Avant de choisir TipTap + WebView, j'ai evalue d'autres approches :

• Markdown natif : plus leger, mais l'experience d'edition est mediocre sur mobile. L'utilisateur doit connaitre la syntaxe Markdown.
• React Native custom avec TextInput : possible pour du gras/italique basique, mais ingerable pour les listes, blocs de code et checklists.
• Quill.js en WebView : similaire a TipTap, mais moins extensible et la communaute est moins active.
• Editeur natif (Swift/Kotlin) : la meilleure performance, mais double le travail de developpement puisqu'il faut maintenir deux codebases.

TipTap + WebView est le meilleur compromis : un seul code pour les deux plateformes, une extensibilite maximale, et une communaute active pour les bugs.

Ce que j'ai appris sur la dette technique des editeurs

Un editeur rich text, c'est le genre de feature qui semble simple en surface mais qui cache une complexite immense. Chaque nouveau format supporte (tableaux, images inline, mentions @) ajoute des interactions imprevues avec le reste du systeme.

La lecon cle : commencer minimal et ajouter progressivement. J'ai lance avec titres + gras + listes. Les checklists sont venues ensuite. Les blocs de code encore apres. A chaque ajout, je validais la stabilite sur les deux plateformes avant de passer au suivant.

C'est exactement la meme philosophie que j'ai appliquee au refactoring de l'architecture : une complexite maitrisee plutot qu'une dette technique qui s'accumule. Ca rejoint aussi les principes que je detaille dans l'article sur la restructuration de la base de donnees.

Si tu developpes une app mobile et que tu envisages un editeur rich text, mon conseil : commence par valider le clavier mobile. Si cette partie fonctionne, le reste suivra. Si elle ne fonctionne pas, aucune quantite de features ne sauvera l'experience utilisateur.

L'editeur de TAMSIV n'est pas le plus puissant du marche — Notion et Craft font mieux. Mais il est suffisant pour le cas d'usage cible, il fonctionne en mode collaboratif, et il s'integre nativement avec le pipeline vocal. Parfois, "suffisant et fiable" vaut mieux que "spectaculaire et instable".

FAQ

TipTap est-il gratuit pour un usage commercial ?

Oui. TipTap est open source sous licence MIT. Le coeur de l'editeur et la majorite des extensions sont gratuits. Seules certaines extensions "Pro" (collaboration avancee, gestion de commentaires) sont payantes, mais elles ne sont pas necessaires pour la plupart des cas d'usage.

Est-ce que l'editeur fonctionne hors ligne ?

L'editeur lui-meme fonctionne parfaitement hors ligne puisqu'il tourne dans une WebView locale. Seule la synchronisation temps reel necessite une connexion. Les modifications sont mises en file d'attente et synchronisees au retour du reseau.

Quelle est la difference entre une checklist "single" et "everyone" ?

En mode "single", un seul membre doit cocher pour valider l'item (ex : "acheter le cafe"). En mode "everyone", chaque membre doit cocher individuellement (ex : "lire le CR"). Le mode est configurable par item dans l'editeur.

Les performances sont-elles correctes sur des appareils d'entree de gamme ?

Oui, avec des precautions. Le lazy loading de la WebView evite de charger l'editeur tant qu'il n'est pas necessaire. Sur les appareils les plus modestes, le temps d'ouverture initial peut atteindre 500ms, mais l'edition reste fluide une fois charge.

Pourquoi ne pas utiliser un CRDT pour la synchronisation ?

Les CRDT (comme Yjs ou Automerge) sont puissants mais ajoutent une complexite significative. Pour des checklists et des memos collaboratifs, la synchronisation par item via Supabase Realtime est suffisante et beaucoup plus simple a maintenir.