Une production de contenu se perd rarement faute d'idées. Elle se perd dans un tableur à quarante colonnes où personne ne sait plus si l'article de mardi attend une relecture, une image ou une décision. Airtable pour le contenu a bonne réputation pour ça : une base, des listes reliées, des vues par statut. Encore faut-il savoir quoi y mettre.
Je fais tourner des machines de contenu qui publient chaque jour. Leur calendrier est la source de vérité : chaque sujet y porte son mot-clé, une note, une date prévue et un statut. Le mien est un fichier versionné ; pour un client, une feuille de calcul en est le miroir. Voici comment je transposerais ces champs dans une base Airtable éditoriale, et ce que je n'y confierais pas.
01Ce qu'une base de contenu doit dire à tout moment
Avant de créer la première table, je me pose quatre questions. Quels sujets sont prévus, et pour quand ? Où en est chacun ? Sur quoi s'appuie-t-il (sources lues, questions réelles) ? Lesquels attendent une décision humaine ? Si votre base ne répond pas à ces quatre questions en un coup d'œil, elle n'est qu'une liste.
Le Nielsen Norman Group distingue deux choses dans son guide de l'inventaire et de l'audit de contenu : l'inventaire liste chaque contenu avec ses attributs (titre, URL, auteur ou propriétaire, sujet, format, date, métadonnées), l'audit juge sa qualité. Le même guide conseille un outil déjà familier, avec une courbe d'apprentissage faible, et rappelle que l'audit se fait par des personnes qui regardent chaque contenu. Une base de contenu sert les deux, mais elle n'audite rien toute seule.
02Trois tables plutôt qu'une grande feuille
La documentation d'Airtable le dit clairement : la bonne pratique est de mettre chaque liste dans une table séparée, puis de relier les enregistrements entre eux par un champ de lien. C'est exactement ce qui manque à un tableur. Une source citée par trois articles y est recopiée trois fois, avec trois orthographes différentes.
Je partirais de trois tables.
La table Sujets
Une ligne par article prévu, avec ces champs :
- un titre de travail et le mot-clé principal ;
- les mots-clés secondaires, en texte simple ;
- une note d'ancrage : à quel service ou à quelle pratique réelle le sujet se rattache, et les pièges à éviter ;
- la date prévue ;
- le statut ;
- l'URL publiée et le verdict du dernier contrôle, une fois l'article en ligne ;
- les liens vers les sources et les questions.
La note d'ancrage est le champ qu'on oublie le plus souvent. Dans mes machines, elle dit d'où vient le sujet et ce qu'il ne faut surtout pas écrire. Sans elle, un sujet n'est qu'un mot-clé, et un mot-clé seul pousse vers des généralités.
La table Sources
Une ligne par page lue : l'URL exacte (la page qui porte l'affirmation, jamais une page d'accueil), un titre au format « Organisme, titre de la page », l'apport (l'affirmation précise que la source soutient), une case « lue » et la date de lecture. L'apport est le champ qui compte. Une source sans apport écrit, c'est une source qu'on citera pour une phrase qu'elle ne contient pas.
La table Questions
Une ligne par question réellement posée, notée telle quelle, avec sa provenance : « Autres questions posées » de Google, onglet Questions de Semrush, forum. Dans mes briefs, une question sans provenance est refusée. Une FAQ inventée répond à des questions que personne ne pose.
03Des statuts qui veulent dire quelque chose
J'utilise cinq statuts : à faire, en cours, brouillon (à relire), publié, en attente. Le dernier est le plus utile. « En attente » veut dire qu'une décision humaine est à prendre : un fait à confirmer, un vécu qui manque pour écrire honnêtement. Ma machine ne traite jamais un sujet en attente. Dans une équipe, c'est la colonne que le responsable éditorial regarde en premier.
Dans Airtable, le statut se met dans un champ à sélection unique, avec « à faire » comme valeur par défaut des nouvelles lignes. Une limite à connaître : Airtable ne garde pas l'historique des changements de ce champ. Sa documentation renvoie vers une automatisation qui horodate chaque changement de statut. Je l'ajouterais dès le premier jour, parce que la question « depuis quand ce sujet est-il en relecture ? » arrive toujours.
Autre règle que j'applique : un seul sujet « en cours » par personne. Deux articles menés de front se contaminent (sources mélangées, liens croisés, statuts oubliés). Mes outils posent un verrou ; dans Airtable, une vue filtrée sur « en cours » par auteur le montre tout de suite.
04Les vues et les automatisations utiles
Une vue Airtable est une façon de regarder la même table : grille, calendrier, kanban, galerie, formulaire. Les données ne changent pas, seul le regard change. Quatre vues me suffiraient : un kanban par statut, un calendrier sur la date prévue, une vue « sources non lues » et une vue « à relire ». Sur les offres payantes, une vue verrouillée empêche un collaborateur d'en modifier les filtres par mégarde.
La démonstration officielle d'Airtable sur un calendrier marketing montre la même logique : les campagnes et les contenus vivent dans deux tables reliées, pour que les détails d'une campagne n'encombrent pas la table des contenus, et la vue calendrier colore chaque date selon le statut. Ce que la vidéo ne montre pas, c'est le travail d'avant : définir ce que veut dire chaque statut. Sans cette définition, les couleurs mentent.
Les automatisations, avec leurs pièges
Une automatisation Airtable a un déclencheur (un enregistrement créé, modifié, qui entre dans une vue, une heure fixe, un webhook) et une ou plusieurs actions. Trois points de la documentation m'ont fait changer de réglage avant même de commencer :
- une exécution est comptée à chaque déclenchement, que l'action réussisse ou non : 100 par mois sur l'offre gratuite, 25 000 sur l'offre Team, par espace de travail ;
- l'action « Run a script » n'existe pas sur l'offre gratuite ;
- un enregistrement qui sort d'une vue et y revient déclenche à nouveau l'automatisation, et les lignes déjà présentes ne déclenchent pas une automatisation nouvelle.
Le troisième point est celui qui fait mal. Si « entre dans la vue À publier » lance une publication, un sujet qui repasse par cette vue part deux fois. Je mettrais donc une condition de garde : l'action ne s'exécute que si le champ « URL publiée » est vide.
Voici la configuration que je monterais en premier :
- Statut modifié : écrire la date et le nouveau statut dans un champ d'historique.
- Entrée dans la vue « à relire » : prévenir le relecteur, avec le lien vers la ligne.
- Chaque lundi matin : envoyer la liste des sujets en attente à la personne qui décide.
La publication elle-même, je la laisse au script qui écrit dans le CMS, comme je l'ai décrit dans mon article sur automatiser la publication avant de produire plus. Airtable déclenche, il ne publie pas.
05Ce qu'Airtable ne fera pas à votre place
Une case « lue » cochée n'est qu'une déclaration. Dans une production de contenu, la défaillance classique, ce sont des URL écrites de mémoire, ou une source citée pour ce qu'elle ne dit pas. C'est pour ça que mes contrôles ouvrent eux-mêmes chaque lien et refusent une source sans apport, comme je l'explique dans l'article sur les sources vérifiées dans un contenu écrit avec l'IA. Une base ne fait pas ce travail.
Google le rappelle dans ses consignes sur le contenu généré par IA : un modèle génératif ne retrouve pas des faits, il prédit une suite de mots probable, et tout texte généré doit être vérifié à la main avant publication. Une base Airtable peut montrer qui doit relire et depuis quand. Elle ne relit pas. Le principe qui tient mes machines est simple : l'outil porte ce qui se vérifie, la rédaction garde ce qui se juge.
Deux limites honnêtes. Si vous êtes seul et publiez quelques articles par mois, Airtable est sans doute de trop : un tableur avec les bonnes colonnes fait le travail. Et je n'utiliserais pas la base comme CMS : le texte publié vit mieux dans un outil fait pour ça, avec brouillons, aperçu et cache, comme Sanity, que j'utilise pour ce site. Mon propre calendrier est un fichier versionné justement pour garder l'historique de chaque changement, ce qu'aucune base ne m'offre aussi simplement.
06Par où commencer lundi
Je ne commencerais pas par Airtable. Je commencerais par écrire, sur une page, les quatre questions de la première partie et les cinq statuts, avec une phrase qui définit chacun. Ensuite seulement :
- Créez les trois tables et reliez-les.
- Importez vos sujets actuels, même incomplets, et marquez « en attente » ceux dont personne ne sait quoi faire.
- Ajoutez la vue kanban et la vue « sources non lues ».
- Ajoutez une seule automatisation, l'horodatage des statuts, et regardez-la tourner une semaine avant d'en ajouter une autre.
Si votre production a dépassé ce stade, la suite tient dans la machine de contenu avec relecture humaine que je fais tourner, et le suivi peut partir seul avec un reporting SEO automatique. Mes services et le portfolio montrent comment je travaille. Si vous voulez qu'on regarde votre base ensemble, on peut en parler.