Les automatisations sont apparues dans Airtable depuis déjà quelques mois.

Après l’avoir essayé sur des dizaines de bases, dans des situations diverses et variées, nous avons pensé qu’il serait utile de vous faire un compte rendu de nos expériences, notamment concernant les limites ou les dangers des automatisations.

Limites des automatisations

C’est un élément dont les utilisateurs d’Airtable sont généralement peu informés mais… il existe des limites aux automatisations dans Airtable.

Par limites, j’entend « quantité » de quelque chose à ne pas dépasser.

A l’heure où je vous écris, voici les limites mises en place par Airtable :

Limite en nombre d’exécutions par mois (fonction du forfait)

Concrètement, cela veut dire que, une fois ce nombre dépassé, vous ne serez plus en mesure d’exécuter vos automatisations. C’est donc un élément essentiel si vous utilisez ces automatisations pour des éléments critiques de votre base Airtable.

Ci-dessous, les limites du nombre d’exécutions d’automatisations Airtable par moi en fonction du forfait :

• Free : 100
• Plus : 5000
• Pro : 50.000
• Entreprise 500.000

Nombre d’automatisations par base

Actuellement, Airtable limite le nombre d’automatisations par base à 25.

Ce n’est pas particulièrement sévère mais il faut garder un oeil là dessus et essayer d’être « économe » lorsque vous concevez des automatisations.

Durée de conservation de l’historique des exécutions

Concrètement, c’est la durée durant laquelle vous pourrez aller retrouver le détail de ce qui s’est produit lors de l’exécution de votre automatisation. A priori, cette donnée ne me semble pas essentielle, et ce, pour plusieurs raisons :

• Vous pouvez « logger » le résultat de vos scripts autre part (ex : webhooks vers un service de logging)
• Le forfait gratuit prévoit déjà 2 semaines d’historique, ce qui me semble assez long.

Néanmoins, voici un récapitulatif de la durée de conservation en fonction des plans :

• Free : 2 semaines
• Plus : 6 mois
• Pro : 1 an
• Entreprise : 3 ans

Limites de l’action « Script »

On parle ici d’une limite spécifique à une action; l’action « script » que l’on peut mettre comme « étape » d’une automatisation.

Ci-dessous, les limites que vous pourriez rencontrer :

• Le script doit s’exécuter en maximum 30 secondes
  Si il prend plus de temps que cela, Airtable va le stopper.
  
• Les scripts peuvent utiliser au maximum 1 seconde de CPU
  Le temps CPU est le temps réellement utilisé pour « exécuter » votre script. Les pauses, les appels à des services extérieurs, etc ne comptent pas dans cette limite, d’où la différence avec les 30 secondes d’exécution.
  
• Les scripts peuvent utiliser au maximum 512Mb de mémoire
  Difficile à contrôler mais, en gros, essayez de manipuler des « petites » quantités de données.
  Evitez de sélectionner tous les records d’une table et ensuite faire une boucle dessus pour vérifier 1 champ.
  Faites plutôt cette vérification dans une formule et créez une vue qui filtre sur le résultat de cette formule, vous serez ainsi certain de ne pas traiter trop de lignes à la fois et ne pas dépasser cette limite.

• Les scripts peuvent faire maximum 50 « Fetch » (= appels à des services externes)
• Les scripts peuvent faire maximum 30 selectRecords.
• Les scripts peuvent faire maximum 15 mutations (create, update ou delete de lignes) par seconde
• Chaque mutation (create, update ou delete de lignes) peut modifier jusqu’à 50 records à la fois.

Optimiser ses automatisations pour éviter les limites

Erreur n°1 : le trigger générique filtré par script

On pourrait être tenté de faire des triggers assez génériques et ensuite de « filtrer » dans le script.

Cette approche peut être une bonne solution dans certaines situations mais gardez à l’esprit que tout déclenchement d’une automatisation, même si le script sort sans effectuer quoi que ce soit, consomme une exécution d’automatisation.

Erreur n°2 : le trigger à date/heure précise quand ce n’est pas nécessaire

Lorsque vous utilisez ce trigger, chaque déclenchement consommera une exécution d’automatisation, même si rien ne s’est produit derrière !

Ce trigger est donc typiquement adapté à des gros volumes car 1 déclenchement pourra « traiter » plusieurs lignes (en utilisant un bloc script par exemple).

Il n’est par contre pas du tout adapté si vous avez un faible volume car il se déclenchera même lorsque vous n’avez rien à traiter…

Erreur n°3 : Choisissez les bons triggers

Exemple : vous avez 10 nouvelles lignes par minute; vous souhaitez toutes les traiter et vous pouvez vous permettre de les traiter 1 fois par heure.

Solution 1 : vous utilisez le trigger « created record » : ce trigger va se déclencher 10 fois par minute et donc 600 fois par heure. Vous allez donc largement dépasser votre limite d’exécutions.

Solution 2 : vous utilisez un trigger planifié et vérifiez toutes les heures. Le trigger se déclenche donc 1 fois par heure et traite tous vos résultats.

Je vous invite vivement à consulter le nouvel article dédié au choix des triggers dans vos automatisations Airtable !

A voir aussi