Apprenez à planifier et construire une appli web pour agences marketing afin de gérer campagnes, assets et validations clients, avec rôles, workflows et historique prêt pour l'audit.
Avant de dessiner des écrans ou de choisir une stack technique, clarifiez le problème central : les campagnes marketing et les validations sont disséminées entre emails, chats et disques partagés. Une application web de campagne doit rassembler briefs, assets, retours et validations en un seul endroit pour que chacun voie la suite — sans courir après des fils de discussion.
La plupart des workflows d'approbation en agence impliquent quatre groupes, chacun avec des besoins différents :
Les validations par email créent des problèmes prévisibles : des délais manqués parce que personne ne voit la dernière demande, des retours vagues du type « rends-le plus percutant » sans détails, plusieurs versions qui circulent et des cycles de révisions causés par des retours en retard ou contradictoires.
Définissez des résultats mesurables pour juger si le produit fonctionne :
Pour la v1, concentrez-vous sur l'ensemble minimal qui maintient campagnes et validations ensemble :
Réservez les fonctionnalités sympathiques pour plus tard : reporting avancé, intégrations profondes, règles d'automatisation et chemins d'approbation personnalisés.
Avant de penser aux écrans ou à la tech, écrivez comment le travail circule réellement dans votre agence. Un workflow clair transforme « Où en est-on ? » en un ensemble prévisible d'étapes que votre appli peut faire respecter, automatiser et reporter.
La plupart des applis d'approbation de campagne se décrivent avec un petit ensemble de briques :
Documentez les relations : une campagne contient des projets ; les projets contiennent des tâches ; les tâches produisent des assets ; les assets passent par des approbations.
Un flux simple, adapté aux agences, est :
Draft → Revue interne → Revue client → Approuvé
Faites en sorte que chaque état ait une signification opérationnelle. Par exemple, « Revue interne » peut exiger la validation d'un lead créatif et du responsable de compte avant que le client ne voie quoi que ce soit.
Décidez de l'apparence des retours dans votre produit :
L'essentiel est de lier les retours à une version d'asset, afin d'éviter les disputes sur le fichier examiné.
Ralentissements courants : attente des réviseurs, étapes suivantes floues et configuration répétée. Les automatisations utiles :
Les validations réelles ne sont pas toujours propres. Prévoyez :
Si vous pouvez décrire ces règles en langage simple, vous êtes prêt à les transformer en écrans et modèles de données.
Une bonne UX pour une appli de campagne commence par une hiérarchie d'information simple qui reflète la manière dont les agences pensent : Client → Campagne → Livrables (assets). Si les utilisateurs peuvent toujours répondre à « Où suis-je ? » et « Que se passe-t-il ensuite ? », les validations s'accélèrent et moins de choses passent entre les mailles.
Utilisez le client comme ancre de niveau supérieur, puis affichez les campagnes en dessous, et enfin les livrables (ads, emails, landing pages, posts sociaux). Conservez la même structure dans la navigation, les breadcrumbs et la recherche pour éviter de faire réapprendre l'application à chaque écran.
Règle pratique : chaque livrable doit toujours afficher en un coup d'œil client, campagne, date d'échéance, statut et propriétaire.
Dashboard : le hub de l'agence. Priorisez ce qui demande de l'attention aujourd'hui : échéances à venir, éléments en attente de revue interne, éléments en attente d'approbation client.
Timeline de campagne : vue calendaire ou par phases qui rend les dépendances évidentes (ex. « Copy approuvé » avant « Design final »). Gardez-la lisible — on doit comprendre l'avancement en quelques secondes.
Vue de revue d'asset : c'est là que l'on gagne — ou perd — du temps. Affichez un aperçu large, rendez les commentaires faciles à trouver et l'action suivante évidente.
Inbox : un endroit unique pour « ce à quoi je dois répondre » (nouveaux retours, demandes d'approbation, mentions). Cela réduit le ping-pong entre email et chat.
Les filtres rapides doivent répondre aux requêtes fréquentes :
L'appel à l'action principal doit être évident : Approuver / Demander des changements. Gardez-le fixe dans la vue de revue (footer/header sticky) pour que les clients ne le cherchent pas après avoir fait défiler les commentaires.
Les clients révisent souvent entre deux réunions. Priorisez la lisibilité mobile : aperçu clair, boutons larges et formulaires courts pour les retours. Si un tap ouvre l'asset et un autre approuve, vous verrez les délais se réduire.
Une appli d'approbation de campagne vit ou meurt selon la confiance : les clients doivent être sûrs de ne voir que ce qu'ils doivent, et votre équipe a besoin de limites claires pour éviter que quelqu'un n'écrase du travail ou n'approuve à tort.
La plupart des agences se débrouillent avec cinq rôles :
Au lieu de permissions globales uniquement, définissez des actions par type d'objet (campagne, livrable, asset, commentaire). Actions typiques : voir, commenter, uploader, approuver, éditer, supprimer.
Un paramétrage pratique par défaut est le « moindre privilège » : les contributeurs peuvent uploader et éditer leurs propres assets, mais la suppression ou la modification des paramètres de campagne est réservée aux account managers/admins.
Les clients ne doivent voir que leurs campagnes, assets et discussions. Évitez les « dossiers clients » partagés qui exposent par erreur d'autres comptes. C'est plus simple quand chaque campagne est liée à un compte client et que les vérifications d'accès sont appliquées partout (pages, téléchargements, notifications).
Supportez deux modes d'approbation par livrable :
Proposez des liens de partage pour la commodité, mais gardez-les privés par défaut : tokens limités dans le temps, mot de passe optionnel et possibilité de révoquer. Règle : le partage ne doit jamais contourner la frontière client — il doit seulement accorder accès à ce que l'utilisateur pourrait normalement voir.
Une fonctionnalité d'approbation client réussit si tout est clair. Si votre équipe et vos clients ne savent pas « qui attend quoi », les validations stagnent et « approuvé » devient discutable.
Commencez par un petit ensemble d'états que tout le monde reconnaît :
Évitez d'ajouter un statut pour chaque cas limite. Si vous avez besoin de nuance, utilisez des tags (ex. « legal review ») plutôt que d'exploser le workflow.
Traitez chaque upload comme une nouvelle version immuable. Ne remplacez pas les fichiers en place — créez v1, v2, v3… liés au même asset.
Cela permet des conversations propres (« Merci de mettre à jour v3 ») et évite les pertes accidentelles. Dans l'UI, mettez en évidence la version courante tout en permettant d'ouvrir les versions antérieures pour comparaison.
Les commentaires libres sont souvent chaotiques. Ajoutez de la structure :
Si vous prenez en charge les timecodes (vidéo) ou les pins région/page (PDF/images), les retours deviennent beaucoup plus exploitables.
Lorsqu'une personne approuve, enregistrez :
Après approbation, définissez les règles : typiquement verrouiller les modifications sur la version approuvée, mais permettre la création d'une révision mineure comme nouvelle version (qui remet le statut à In Review). Cela rend l'approbation défendable sans bloquer des ajustements légitimes de dernière minute.
Les validations créatives réussissent ou échouent selon la facilité d'accès au bon fichier au bon moment. La gestion des assets est souvent l'endroit où les applis de campagne deviennent frustrantes — téléchargements lents, noms de fichiers confus et boucles « quelle version est finale ? ».
Un bon schéma : stockage d'objets pour les fichiers binaires (rapide, scalable, économique) et base de données pour les métadonnées (recherchable et structurée).
Votre base doit suivre : nom d'asset, type, campagne, version courante, qui l'a uploadé, horodatages, état d'approbation et URLs d'aperçu. La couche de stockage contient le fichier binaire et éventuellement des dérivés comme miniatures.
Ciblez un petit ensemble couvrant la majorité des workflows :
Soyez explicite dans l'UI sur ce qui est uploadable vs lien-seulement. Cela réduit les uploads ratés et les tickets support.
Les aperçus accélèrent la revue et sont plus conviviaux pour les clients. Générez :
Cela permet aux parties prenantes de parcourir un dashboard de livrables sans télécharger les fichiers haute résolution.
Définissez les limites tôt (taille max, nombre max par campagne, extensions supportées). Validez le type et le contenu (ne faites pas confiance aux extensions). Si vous travaillez avec des clients enterprise ou acceptez de gros fichiers, pensez à scanner virus/malware dans le pipeline d'upload.
Les validations demandent souvent traçabilité. Définissez ce que signifie « supprimer » :
Associez cela à des politiques de rétention (ex. conserver les assets 12–24 mois après la fin de la campagne) pour maîtriser les coûts de stockage.
Une appli de campagne avec validations clients n'a pas besoin d'infrastructure exotique. Elle a besoin de frontières claires : une interface conviviale pour les humains, une API qui applique les règles, un stockage pour les fichiers et les données, et des workers en arrière-plan pour le travail temporel comme les rappels.
Commencez par ce que votre équipe peut construire et exploiter. Si vous maîtrisez déjà React + Node, ou Rails, ou Django, c'est généralement le bon choix pour la v1. Les préférences d'hébergement comptent aussi : si vous voulez la simplicité « push to deploy », choisissez une plateforme qui supporte bien votre stack et facilite logs, scalabilité et gestion des secrets.
Si vous voulez avancer plus vite sans un gros cycle de build-from-scratch, une plateforme « vibe-coding » comme Koder.ai peut aider à prototyper et itérer le workflow (campagnes, assets, approbations, rôles) via une interface chat — puis exporter le code source quand vous voulez reprendre la main.
Frontend (web app) : Dashboards, timelines de campagne et écrans de revue. Il communique avec l'API et gère les détails UX en temps réel (états de chargement, progression d'upload, fils de commentaires).
API backend : Source de vérité pour les règles métier — qui peut approuver, quand un asset est verrouillé, quelles transitions d'état sont autorisées. Gardez ça simple et prévisible.
Base de données : Stocke campagnes, tâches, approbations, commentaires et événements d'audit.
Stockage de fichiers + génération d'aperçus : Stockez les uploads dans un stockage d'objets (ex. compatible S3). Générez miniatures/aperçus pour permettre la revue sans télécharger les fichiers complets.
Jobs en arrière-plan : Tout ce qui ne doit pas bloquer l'utilisateur : envoi d'emails, génération d'aperçus, rappels planifiés, rapports nocturnes.
Pour la plupart des agences, un monolithe modulaire est idéal : une base de code backend avec modules bien séparés (assets, approbations, notifications). Vous pouvez ajouter des services là où ils aident vraiment (ex. worker dédié) sans éclater en nombreux déploiements.
Traitez les notifications comme une fonctionnalité à part entière : in-app + email, avec options de désabonnement et fil clair. Une queue (BullMQ, Sidekiq, Celery, etc.) permet d'envoyer des rappels de manière fiable, de retenter les échecs et d'éviter de ralentir uploads et validations.
Prévoyez trois environnements dès le départ :
Si vous souhaitez creuser la partie données ensuite, poursuivez avec /blog/data-model-and-database-design.
Un modèle de données propre garde votre appli de campagne simple même en croissance. L'objectif : rendre les écrans courants (listes de campagnes, files d'attente d'assets, pages d'approbation) rapides et prévisibles, tout en capturant l'historique dont vous aurez besoin.
Commencez par un petit ensemble de tables correspondant au fonctionnement réel des agences :
Conservez des IDs cohérents (UUIDs ou IDs numériques — les deux vont). L'important : chaque enregistrement enfant (clients, campaigns, assets) porte un organization_id pour faire respecter l'isolation des données.
Les statuts seuls n'expliquent pas ce qui s'est passé. Ajoutez des tables comme :
Cela rend la piste d'audit et la responsabilité simples sans alourdir vos tables principales.
La plupart des écrans filtrent par client, statut et date d'échéance. Ajoutez des index tels que :
Considérez aussi un index composé pour « ce qui a besoin d'une revue maintenant », ex. (organization_id, status, updated_at).
Traitez votre schéma comme du code produit : utilisez des migrations pour chaque changement. Seedez quelques templates de campagne (stages par défaut, statuts sample, étapes d'approbation standards) pour que les nouvelles agences démarrent vite et que vos environnements de test aient des données réalistes.
Une appli d'approbation client vit ou meurt selon la confiance : les clients ont besoin d'une connexion simple, et votre équipe doit être sûre que seules les bonnes personnes voient le travail. Commencez par le plus petit ensemble de fonctionnalités d'auth qui semble « prêt pour l'agence », puis étendez.
Si vos utilisateurs sont surtout des clients qui se connectent ponctuellement, email + mot de passe est souvent la voie la plus fluide. Pour les grandes organisations (ou clients enterprise), envisagez le SSO (Google/Microsoft) pour qu'ils utilisent leurs comptes existants. Vous pouvez supporter les deux plus tard — évitez de rendre le SSO obligatoire sauf si votre audience l'attend.
Les invitations doivent être rapides, conscientes des rôles et tolérantes :
Un bon pattern : un lien magique pour définir un mot de passe, afin que les nouveaux utilisateurs n'aient rien à retenir au départ.
Utilisez une gestion de session sécurisée (tokens d'accès courte durée, refresh tokens rotatifs, httpOnly cookies quand possible). Ajoutez un flux de réinitialisation de mot de passe standard avec tokens expiring et à usage unique et écrans de confirmation clairs.
L'authentification répond à « qui êtes-vous ? » L'autorisation répond à « que pouvez-vous faire ? » Protégez chaque endpoint avec des vérifications de permissions — surtout pour les assets de campagne, commentaires et approbations. Ne comptez pas uniquement sur le masquage UI.
Conservez des logs auditables (tentatives de connexion, acceptation d'invite, changement de rôle, activité suspecte), mais évitez de stocker des secrets. Loggez identifiants, horodatages, indices IP/appareil et résultats — jamais mots de passe bruts, contenus de fichiers entiers ou notes clients privées.
Les notifications font qu'une appli de campagne est utile — ou accablante. L'objectif : faire avancer le travail sans transformer chaque commentaire en incendie de boîte de réception.
Commencez par un petit ensemble de déclencheurs à fort signal et gardez-les cohérents entre email et in-app :
Faites en sorte que chaque notification indique le « quoi » et l'action suivante avec un lien direct vers la vue adéquate (ex. page de revue d'asset ou inbox).
Différents rôles veulent différents niveaux de détail. Donnez du contrôle au niveau utilisateur :
Defaults intelligents : les clients veulent généralement moins d'emails que les équipes internes et se soucient surtout des éléments demandant leur décision.
Regroupez les mises à jour similaires (ex. « 3 nouveaux commentaires sur la bannière d'accueil ») plutôt que d'envoyer un email par commentaire. Ajoutez des garde-fous :
Une Approval Inbox dédiée réduit les allers-retours en montrant seulement ce que le client doit faire maintenant : éléments « En attente de vous », dates d'échéance et un chemin en un clic vers la bonne vue de revue. Gardez-la épurée et accessible, et liez-la depuis chaque email de revue (ex. /approvals).
L'email n'est pas garanti. Stockez le statut de livraison (envoyé, rebond, échoué) et retentez intelligemment. Si un email échoue, affichez-le aux admins dans une vue d'activité et basculez sur les notifications in-app pour que le workflow ne stagne pas en silence.
Quand les clients approuvent du créatif, ils ne se contentent pas de cliquer — ils prennent une responsabilité. Votre appli doit rendre cette piste de décision facile à trouver, claire et difficile à contester plus tard.
Implémentez un fil d'activité à deux niveaux :
Rendez les entrées lisibles pour des utilisateurs non techniques avec un format cohérent : Qui a fait quoi, quand et où. Par ex. : « Jordan (Agence) a uploadé Homepage Hero v3 — 12 déc., 14:14 » et « Sam (Client) a approuvé Homepage Hero v3 — 13 déc., 09:03 ».
Pour la responsabilité, conservez une piste d'audit pour :
Règle pratique : si un événement affecte les livrables, le timing ou une validation client, il appartient à la piste d'audit.
Les événements d'audit doivent être immuables. Si quelque chose doit être corrigé, enregistrez un nouvel événement (ex. « Approbation rouverte par l'agence ») plutôt que de réécrire l'historique. Autorisez les éditions pour des champs d'affichage (typo dans un titre d'asset) mais logguez toujours que l'édition a eu lieu.
Permettez d'exporter un résumé simple (PDF ou CSV) pour la remise : versions finales approuvées, horodatages d'approbation, retours clés et liens vers les assets. Utile à la clôture de projet ou lors d'un changement d'équipe client.
Bien fait, cela réduit la confusion, protège les deux parties et rend votre logiciel de gestion de campagne digne de confiance — pas compliqué.
Le reporting et les intégrations peuvent vite gonfler le périmètre d'une appli d'approbation. L'astuce : livrer le plus petit ensemble qui aide les équipes au quotidien, puis étendre selon l'usage réel.
Débutez par une vue de reporting simple (ou widgets de dashboard) pour les checks hebdomadaires et la triage quotidien :
Ajoutez ensuite des indicateurs de santé de campagne faciles à lire :
Ces signaux n'ont pas besoin d'une prévision parfaite — juste des règles claires et cohérentes.
Les intégrations doivent réduire le travail manuel, pas créer de nouveaux points de défaillance. Priorisez selon les habitudes quotidiennes de vos utilisateurs :
Même si vous ne publiez pas d'API publique immédiatement, définissez une stratégie d'extension claire :
Phase 1 : dashboards de base + listes pending/overdue.
Phase 2 : indicateurs de santé + tendances de temps de cycle.
Phase 3 : 1–2 intégrations à fort impact (généralement email + Slack).
Phase 4 : webhooks et API prête pour des partenaires.
Si vous envisagez de proposer des niveaux avec reporting et intégrations, gardez-les simples et transparents (voir /pricing). Si vous voulez aller plus vite sur un MVP, Koder.ai peut aussi aider : itérez le workflow d'approbation en « planning mode », déployez une build hébergée pour des retours, et revenez via snapshots en affinant les exigences.
Pour des patrons de workflow plus avancés, voyez aussi les guidances liées depuis /blog.
Commencez par définir le problème central : les validations et les retours sont éparpillés entre email, chat et fichiers partagés. Votre v1 doit centraliser briefs, assets, retours et validation afin que chaque partie prenante puisse répondre rapidement :
Utilisez des résultats mesurables comme le délai de validation et le nombre de cycles de révision pour limiter la portée et vérifier les améliorations.
Concevez autour de quatre groupes courants :
Si vous optimisez uniquement pour les utilisateurs internes, l'adoption par les clients (et la rapidité des validations) en souffrira généralement.
Choisissez un petit ensemble de métriques liées aux frictions réelles :
Instrumentez ces métriques dès le début pour valider les améliorations après le lancement de la v1.
Une v1 pratique inclut :
Repoussez les rapports avancés, intégrations profondes, règles d'automatisation et chemins d'approbation personnalisés jusqu'à validation d'usage.
Modélisez le flux de travail avec quelques objets centraux :
Puis définissez un cycle d'approbation (par ex. Draft → Internal review → Client review → Approved) où chaque état a une signification opérationnelle (qui peut le déplacer, quelles conditions, et ce qui se passe ensuite).
Toujours lier les retours à une version d'asset pour éviter les disputes « quelle version ? ». Bonnes pratiques :
La structure rend les retours actionnables et réduit les retouches inutiles.
Gardez la navigation centrée sur une hiérarchie simple : Client → Campagne → Livrables (assets). Écrans « quotidiens » clés :
Ajoutez des filtres qui répondent aux questions réelles : client, date d'échéance, statut, responsable.
Commencez simple avec des rôles couvrant la plupart des besoins :
Puis définissez des permissions (campagne, asset, commentaire, approbation) comme voir/commenter/uploader/valider/éditer/supprimer. Appliquez le principe du « moindre privilège » et vérifiez les autorisations côté backend — ne vous fiez pas uniquement au masquage UI.
Traitez chaque upload comme une version immuable (v1, v2, v3…). Ne remplacez pas les fichiers en place.
Enregistrez les métadonnées d'approbation :
Verrouillez généralement la version approuvée mais autorisez la création d'une nouvelle version (qui remet le statut à In Review) si des changements sont nécessaires.
Une architecture simple comprend :
Pour la v1, un monolithe modulaire avec un worker pour les jobs est souvent plus simple à livrer et opérer qu'une multitude de services.
