> ## Content Index
> Fetch the complete content index at: https://www.airtablefacile.fr/llms.txt
> Use this file to discover other available public pages before exploring further.

# #ERROR! dans une formule Airtable : les 4 causes (et comment les corriger)
- URL: https://www.airtablefacile.fr/error-dans-une-formule-airtable-les-4-causes-et-comment-les-corriger/
- Published: 2026-07-14T15:21:02.000Z
- Updated: 2026-07-15T11:34:48.000Z
- Description: Un #ERROR! dans une formule Airtable vient presque toujours de 4 causes : champ vide, division par zéro, Lookup en tableau ou mélange de types. Le réflexe IF() qui les corrige.
- Author: Florian
- Tags: Airtable, ⚡️ Formules, 🧑🏻‍💻 Tutoriels

Vous avez écrit une formule, tout semblait bon, et pourtant votre champ affiche un affreux **#ERROR!**. C'est l'un des problèmes les plus fréquents sur Airtable, et l'un des plus frustrants, parce que le message ne dit pas *pourquoi*.

J'ai compilé des dizaines de cas rencontrés par des utilisateurs (et par mes clients). On retombe toujours sur les mêmes coupables. Voici les **4 causes principales**, et le réflexe qui règle la grande majorité des cas.

![Les 4 causes du #ERROR! et le réflexe IF()](https://storage.ghost.io/c/a7/af/a7af63c4-ad2b-4c52-83ba-3816673d766c/content/images/2026/07/illus-error-1-causes.png)

Les 4 causes classiques du #ERROR!, et le réflexe IF() qui les neutralise.

## Cause n°1 : un champ vide

C'est de loin la plus fréquente. Vous faites un calcul sur un champ qui, pour certains enregistrements, est **vide** : une date non renseignée, un nombre absent, un champ pas encore rempli. Airtable ne sait pas quoi calculer, et renvoie #ERROR!.

## Cause n°2 : une division par zéro

Diviser par zéro (ou par un champ vide, ce qui revient au même) est impossible. Dès qu'un dénominateur vaut zéro, la formule casse. Exemple typique : un « prix moyen » calculé en divisant un total par une quantité qui, parfois, est à zéro.

## Cause n°3 : un Lookup qui renvoie un tableau

Celle-là piège presque tout le monde. Un champ **Lookup** ne renvoie pas une valeur unique, mais une **liste** de valeurs, même quand cette liste ne contient qu'un seul élément. Impossible de calculer directement dessus. La solution : un champ **Rollup**, qui renvoie automatiquement une seule valeur via une formule d'agrégation (SUM, AVERAGE, MAX…).

![Lookup renvoie une liste, Rollup agrège en une valeur](https://storage.ghost.io/c/a7/af/a7af63c4-ad2b-4c52-83ba-3816673d766c/content/images/2026/07/illus-error-2-lookup-rollup.png)

Un Lookup renvoie une liste ; pour calculer sur un champ lié, passez par un Rollup.

## Cause n°4 : un mélange de types

Vous demandez une opération entre des **types incompatibles** : du texte là où la formule attend un nombre, une date traitée comme du texte. Airtable est strict là-dessus. « 12 » (texte) et 12 (nombre) ne sont pas la même chose pour lui.

Deux champs qui semblent tous les deux être des nombres peuvent en réalité cacher un champ texte et un champ nombre : l'addition renvoie alors #ERROR!. Même piège avec les dates : vous tentez un DATEADD sur un champ qui affiche une date, mais qui n'est qu'une représentation textuelle de cette date. Avant d'écrire votre formule, vérifiez le vrai type de chaque champ.

## Le vrai piège : les champs formule

Pour un champ natif, le type est évident : une date est une date, un nombre est un nombre, du texte est du texte. La difficulté arrive avec les champs calculés, les formules. Une formule affiche une donnée qui semble d'un certain type, alors qu'elle en renvoie un autre. Vous voyez une date à l'écran, mais Airtable manipule du texte.

Comment connaître le vrai type retourné par une formule ? Ouvrez ses options de formatage. Les options disponibles trahissent le type :

- un format de date, avec le choix 12h/24h : la formule renvoie une date ;
- des décimales, un symbole de devise : elle renvoie un nombre ;
- aucune option de ce genre : elle renvoie du texte.

Ce réflexe vous évite des heures de #ERROR! inexplicables.

## Le réflexe qui règle la grande majorité des cas

La plupart de ces erreurs viennent d'une valeur manquante ou inattendue. La bonne pratique tient en une règle : **testez avant de calculer**.

Encapsulez votre calcul dans un `IF()` qui vérifie que le champ est bien rempli **avant** de faire l'opération :

```
IF({Montant}, {Montant} * 1.21, "")
```

Traduction : s'il y a un montant, calcule, sinon n'affiche rien. Pas de valeur, pas de calcul, pas d'erreur.

Pour les divisions, même logique en testant le dénominateur :

```
IF({Quantite}, {Total} / {Quantite}, 0)
```

## Bonnes habitudes pour ne plus voir de #ERROR!

- Testez systématiquement vos champs avec `IF()` avant tout calcul.
- Pour les champs liés, préférez un **Rollup** à un Lookup dès que vous voulez calculer.
- Vérifiez les **types** : un champ « nombre » doit être un nombre, pas du texte.
- Pensez aux enregistrements incomplets. Votre formule doit fonctionner **même quand les données manquent**.

## En résumé

Dans 9 cas sur 10, un #ERROR! vient d'un champ vide, d'une division par zéro, d'un Lookup mal utilisé ou d'un mélange de types. Un simple `IF()` de sécurité en amont vous évite la grande majorité de ces galères.

*Et vous, c'est quoi le #ERROR! qui vous a fait perdre le plus de temps ? Partagez votre formule en commentaire, on la débogue ensemble.*