Un fichier Excel partagé commence toujours bien. Puis arrivent la deuxième personne, la copie « version finale », l’onglet que personne n’ose supprimer et la colonne qui ne veut plus rien dire. Un jour, deux collègues donnent deux chiffres différents pour le même client, et chacun a raison selon son fichier.
Remplacer Excel par Airtable règle ce problème, à une condition : ne pas recopier le tableur tel quel dans un nouvel outil. Voici la méthode que je suis, en cinq étapes, avec deux exemples réels. C’est aussi le fil des deux jours de la formation Airtable.
Le tableur partagé : ce qu’il coûte vraiment
Le problème n’est pas Excel. Pour un calcul, une simulation ou un fichier qu’une seule personne tient à jour, un tableur reste le bon outil. Il devient un problème quand il sert de base de données à toute une équipe. Les signes sont toujours les mêmes :
- des versions multiples : la pièce jointe d’un e-mail, la copie sur le Drive, le fichier « à jour » sur le poste de quelqu’un ;
- des saisies contradictoires : un nom écrit de trois façons, une date au format texte, un statut que chacun invente ;
- des onglets qui se dupliquent : un par commercial, un par mois, un par chantier, avec les mêmes clients recopiés dans chacun ;
- un fichier qu’on n’ose plus toucher, parce qu’une formule cachée casse dès qu’on insère une colonne.
Chacun de ces signes coûte du temps chaque semaine, en recherches, en vérifications et en corrections. Et il bloque toute automatisation : un scénario Make ou n8n ne peut pas s’appuyer sur un fichier dont la structure change au gré des utilisateurs.
Étape 1 : faire l’inventaire de ce qui ne va plus
Avant d’ouvrir Airtable, je regarde le fichier actuel avec ceux qui s’en servent. Quelles colonnes sont vraiment remplies ? Quelles informations sont saisies deux fois ? Qui a besoin de quoi, et à quel moment ? Cette demi-heure évite le piège le plus courant : reproduire dans Airtable les défauts du tableur.
L’inventaire sert aussi à choisir par où commencer. Un seul processus, celui qui fait perdre le plus de temps, et pas toute l’entreprise d’un coup.
Étape 2 : penser en tables reliées
C’est le passage mental qui change tout. Dans un tableur, une ligne contient tout : le client, le chantier, l’intervention, la facture. Dans une base, chaque chose a sa table : les clients d’un côté, les chantiers de l’autre, les interventions dans une troisième. Les tables sont ensuite reliées entre elles.
Le bénéfice est immédiat : le nom du client est saisi une seule fois. Quand son adresse change, elle change partout. Et depuis la fiche d’un client, on voit tous ses chantiers, sans filtre ni recherche.
Mon conseil : dessinez les tables sur une feuille avant de les créer. Si vous n’arrivez pas à dire en une phrase ce que contient une table, c’est qu’elle en mélange deux.
Étape 3 : choisir les bons champs et empêcher la saisie fausse
Un tableur accepte tout dans n’importe quelle cellule. Airtable, lui, permet de typer chaque champ : liste fermée, date, pièce jointe, personne, case à cocher, champ calculé, agrégation depuis une table liée. Ce choix décide de tout ce qui suivra.
- Un statut devient une liste fermée : plus de « en cours », « En cours » et « encours » dans la même colonne.
- Une échéance devient une vraie date, sur laquelle on peut trier, filtrer et déclencher un rappel.
- La saisie extérieure passe par un formulaire qui alimente la base directement, sans recopie.
Le principe : empêcher l’erreur à la source plutôt que de la corriger après.
Voici à quoi cela ressemble dans une vraie base, celle que j’ai construite pour publier les posts d’artisans sur les réseaux sociaux. Une ligne par publication, et des colonnes qui ont chacune un type : la date de publication voulue est une date, le statut est une liste fermée (brouillon, planifié, publié), le texte court est la phrase saisie par l’artisan, le texte de publication est celui que l’IA rédige à partir d’elle, et le média est une pièce jointe. Le titre de chaque ligne se calcule seul, à partir du statut et de la date. Une seconde table, « Configuration », réunit les réglages, comme le contexte de l’entreprise.
Côté saisie, l’artisan ne voit jamais ce tableau. Il passe par un formulaire de deux champs, tous deux obligatoires : quelques lignes sur le sujet du post, et une photo ou une vidéo. Le formulaire précise même les formats acceptés. Impossible d’enregistrer un post sans image, ou une vidéo dans un format que les réseaux refuseront.
Étape 4 : une vue par usage, plutôt qu’un fichier par personne
Dans un tableur, chacun finit par se faire sa copie, filtrée à sa façon. Dans Airtable, la même donnée se présente en plusieurs vues : l’atelier voit ses interventions de la semaine, le commercial ses affaires en cours, la direction un tableau de synthèse. Tout le monde travaille sur la même base, et personne ne duplique le fichier.
Pour ceux qui ne doivent pas voir la base entière, une interface leur donne un écran simple, avec seulement les champs utiles. C’est ce qui a rendu possible le projet des artisans ci-dessous.
Dans la base des artisans, l’interface remplace le tableau par une galerie : chaque post apparaît comme une carte, avec sa photo, son texte court, son statut et sa date. Quatre onglets la filtrent : brouillons, planifiés, publiés, et tous les posts. Le bouton « Nouvelle publication » ouvre le formulaire vu plus haut. L’artisan travaille sur ces cartes, depuis son téléphone ou son ordinateur, sans jamais ouvrir la base.
Une deuxième page de la même interface sert de tableau de bord : le nombre total de posts, puis le nombre de brouillons, de planifiés et de publiés, avec un graphique. Il se met à jour tout seul, sans export ni recopie. C’est ce que le tableur partagé ne savait pas faire sans une heure de copier-coller.
Étape 5 : migrer un processus en entier, puis automatiser
On bascule un vrai processus, de bout en bout, avec les vraies données. Pas un essai à moitié rempli qu’on abandonne au bout de deux semaines, parce que l’ancien fichier reste ouvert à côté. Le jour de la bascule, l’ancien tableur passe en lecture seule.
Ensuite seulement vient l’automatisation. D’abord celle qu’Airtable sait faire seul : un rappel, une affectation, un changement d’état. Dans la base des artisans, quatre automatisations natives tiennent le statut à jour sans que personne y pense. Quand la date de publication voulue est renseignée, le post passe en « planifié ». Quand la date de publication réelle est inscrite, il passe en « publié ». Et si l’une de ces dates est effacée, le statut revient en arrière. Chacune tient en deux blocs : un déclencheur, « lorsqu’une entrée correspond aux conditions », et une action, « mettre à jour l’entrée ».
Puis, quand cela ne suffit plus, Airtable devient la base sur laquelle s’appuient vos scénarios Make ou n8n. Si vous hésitez entre les deux, j’ai comparé Make et n8n pour une PME.
Deux exemples réels
Des artisans qui publient en trois gestes
C’est la base que vous avez vue écran par écran plus haut. L’artisan prend une photo de chantier, écrit une phrase et choisit une date, depuis son téléphone. Airtable rédige le texte du post, qui reste en brouillon tant qu’il n’est pas validé. Un scénario Make passe chaque jour, envoie les posts arrivés à échéance vers Buffer, puis inscrit la date de publication dans la fiche : un post ne part jamais deux fois. Le détail est sur la page du projet des artisans.
Ici, la base remplace la mémoire de l’artisan : ce qui est parti, ce qui attend, ce qui reste à valider.
Un cabinet d’avocat qui prépare trois mois de publications en quinze minutes
Pour un cabinet d’avocat, Airtable tient le calendrier, les textes et les images des publications, rattachées aux domaines du droit du cabinet. Un scénario Make génère un trimestre entier en une passe. L’équipe relit, corrige et programme : quinze minutes, contre plusieurs journées avant. La plateforme a été construite pendant les deux jours de formation, et le cabinet la fait tourner seul depuis. Tout est sur la page du projet du cabinet d’avocat.
Votre tableur est-il prêt à être remplacé ?
Quatre questions suffisent pour le savoir :
- Plus de deux personnes modifient-elles le même fichier chaque semaine ?
- La même information (un client, un produit, un chantier) est-elle saisie à plusieurs endroits ?
- Vous est-il déjà arrivé de ne pas savoir quelle version était la bonne ?
- Aimeriez-vous qu’une partie de ce fichier se remplisse ou se mette à jour toute seule ?
Deux « oui » suffisent : le tableur a atteint sa limite, et la migration vous fera gagner du temps dès le premier processus.
Le faire soi-même, ou se faire accompagner
Ces cinq étapes se suivent seul, avec de la rigueur et un peu de temps. L’étape 2, le découpage en tables, est celle où l’on se trompe le plus, et une erreur de structure se paie ensuite dans chaque vue et chaque automatisation.
La formation Airtable suit exactement ce chemin en deux jours, sur vos propres fichiers et non sur un compte de démonstration : on migre un premier processus le premier jour, on l’automatise le second. Si vous voulez d’abord savoir quel processus migrer en premier, je vous propose un audit gratuit de 30 minutes.
