Toutes les agences ont le même processus, et personne ne l’a choisi. Quelqu’un rédige les publications. Quelqu’un fait des captures. Les captures partent par mail ou par messagerie. Le client répond à l’une d’elles. La moitié des retours arrive en note vocale. Puis quelqu’un retape la version validée dans le planificateur en espérant qu’elle est la bonne.
Ce qui casse là-dedans
- Le texte validé et le texte programmé sont deux objets tenus à jour à la main
- Les retours vivent dans un fil que personne ne retrouvera dans deux semaines
- Personne ne peut répondre à « c’est validé ? » sans relire une conversation
- Celui qui valide et celui qui publie sont deux personnes — les erreurs ne se voient donc qu’en public
La validation comme état, pas comme conversation
L’alternative est si simple qu’elle paraît évidente : la publication a un état. Un rédacteur l’écrit, et elle attend. Quelqu’un qui en a le droit la valide. Avant cela, le publieur n’y touche pas — non par politesse, mais parce que le worker ne prend que les publications à l’état validé.
Ce seul changement supprime la ressaisie par laquelle les erreurs entrent, et rend la question lisible d’un coup d’œil.
Des rôles qui valent la peine
- Propriétaire — tout, y compris qui d’autre est là
- Admin — valide les publications, gère les comptes connectés
- Rédacteur — écrit ; ses publications attendent la validation
- Observateur — peut regarder, pas toucher
L’essentiel est que le contrôle se trouve là où sont les données, pas dans l’interface. Cacher un bouton est une politesse ; refuser la requête est la vraie règle.