No-code ou low-code pour une application de gestion développée avec AirTable & Zapier ... that is the question !

Introduction

Pour faire suite à notre précédent article nous avons expérimenté pour nos propres besoins internes @Octo, le développement d’une application de gestion en no-code. Cet article détaille l’avancée de nos réflexions.

L’application à développer est à destination d’une petite équipe sans ressource IT interne (càd. hors périmètre de notre DSI). Sur le papier, elle est une candidate “idéale” pour les outils no-code. Au démarrage et vue d’avion nous pensions en effet aboutir à une petite application de gestion en no-code.

Pourtant, dès le départ pour éviter les chausse-trapes nous avons eu besoin de compétences en conception d’applications. Puis assez rapidement, nous faisons le constat que nous avons besoin d’entrer dans l’univers du low-code pour couvrir nos besoins. Il faut dire qu’une application qui contient une dizaine d'objets / tables en relation avec des problématiques de processus et d'intégration avec d’autres outils, dans l’univers des outils no-code devient une véritable application plus si petite/simple que cela.

Alors le low-code a-t-il tué le no-code ?; Source

Alors le low-code a-t-il tué le no-code ? Non ! Et c’est moins grave qu’il n’y paraît, les compétences nécessaires restent limitées et/ou sont répandues. Enfin, les dérives sont facilement évitables en adoptant une gouvernance assez similaire à celle adoptée lors de l’adoption d’un progiciel métier : rester dans l’utilisation des fonctionnalités offertes nativement par l’outil no-code et n’utiliser les possibilités low-code de l’outil (scripting) que de manière dérogatoire lorsque cela permet un gain de productivité important.

Dans cet article, nous présentons notre retour d’expérience du développement d’une application de gestion avec AirTable et Zapier. En sus de l’analyse classique  - contexte, démarche, avantages, limites - de notre expérimentation à proprement parlé, vous y trouverez une prise de recul vis à vis de ce type d’outillage no-code et en particulier, des éléments de réponses sur les coûts et à la question “Est-ce-que c’est fait pour moi”.

Note : le contenu de cet article est d’un niveau technique “simple” pour les informaticiens … un peu plus élevé pour les néophytes. Non-techniciens de l’informatique, no-coders et intrapreneurs ne vous découragez pas vous en capturerez des messages clés pour vous…..et vous serez tôt ou tard confrontés aux problématiques que nous abordons ;-)

Contexte

Une équipe de 4 personnes sans ressource IT gère le suivi opérationnel, la facturation et le paiement de freelances (informaticiens, UX designers, ....).

Douleurs ressenties, outils principaux actuels et leurs limites

Le constat de l’équipe est sans ambiguïté, au travers des 5 ou 6 outils comme des GSheet, Trello, un outil de gestion des CRAs (Compte Rendu d’Activité) ou un développement spécifique (pour gérer les freelances), trop de données sont réparties dans ces différents applicatifs et empêchent d’avoir une vision rapide et synthétique des freelances actifs sur les projets à un instant t. Aucun des outils n'offre un moyen simple d'obtenir ces infos. Enfin, des doubles, des triples, voire des quadruples saisies des données (~12 data) causent une perte de temps opérationnelle et un risque d’erreurs.

En particulier, sur un extranet de gestion de CRA, une ressaisie & une vérification des CRAs nécessite 2h de travail chaque fin de mois. Enfin, au niveau de GSheet, chaque mois, un formulaire soumis et rempli par les freelances (outil de type “Survey/Google forms”) permet de l'alimenter pour partie. La modélisation embarquée dans les GSheet ne correspond pas (plus) aux besoins de l’équipe. De fastidieuses manipulations, des duplications de données, des contrôles, des filtrages, stressent l’équipe à chaque fin de mois.

De fastidieuses manipulations, des duplications de données, des contrôles, des filtrages, stressent l’équipe à chaque fin de mois; Source

Volumes de données

• Quelques centaine de freelances enregistrés dont environ un tiers sont actifs chaque mois.
• Les GSheets de suivi d'activité contiennent quelques centaines de lignes
• Tous les mois quelques centaines d’emails partent à destination des freelances en activité. Les emails contiennent un lien vers un formulaire GForm prérempli que complètent les freelances et qui une fois soumis en retour alimentent les GSheet de suivi.

Démarche & Résultat

La prise de contexte

Dans une démarche simple nous entamons un mini cadrage en commençant par collecter et interviewer l’équipe. Ainsi nous les rencontrons et collectons ;

• La documentation des processus existants
• Les douleurs rencontrées sur l'existant
• Les attendus fonctionnels en cible
• Le premier MCD (Modèle de Conception des Données) dessiné par l'équipe

Puis, dans des mini ateliers de conception applicative nous construisons un MCD cible sur la base du MCD récupéré.

Notre MCD final contient une dizaine de tables, ce qui en fait une application de gestion certes modeste mais qui nécessite tout de même d’avoir quelques connaissances en conception applicative et qui dans un environnement no-code n’est pas aussi trivial à appréhender (voir chapitres “Est-ce que c’est fait pour moi ?” et “Limites rencontrées”).

Le choix de la plateforme cible

L’outil opérationnel pivot sur lequel nous pouvons agir et qui concentre le plus d’insatisfactions sont les GSheet.

Pour répondre aux problèmes de modélisation dans ces dernières et pour structurer les données, nous arrêtons notre choix sur la solution no-code AirTable. Cette dernière offre par ailleurs une interface suffisamment conviviale pour être utilisée par les opérationnels.

Le développement sous AirTable et … Zapier

C’est parti, nous aboutissons en 2j à peine à une application V1 constituée d'environ 10 objets. Dans AirTable cela se traduit par un mix de tables & vues (voir chapitre “Limites rencontrées”).

Après une démo, l’appropriation par les opérationnels de l'application et de l'outil AirTable est relativement rapide puisqu’ils entament eux-mêmes des premières opérations de refactoring sur la base de la V1 de l’application.

Par la suite, les échanges avec l’équipe nous emmène vers un cahier des charges d’une V2 intégrant un processus d’envoi automatisé par email d’un formulaire aux freelances. L’envoi se déclenche sur la base de critères / valeurs contenus dans les champs d’une table.

Après 2j, la V2 inclut alors un “scripting block” (voir chapitre “Est-ce que c’est fait pour moi ?) "Envoyer CRA", qui boucle sur une table (CRA) et insère des enregistrements dans une seconde table. Cette dernière contient les informations utiles pour l’envoi d’un email de rappel aux freelances pour qu’ils saisissent leurs CRAs. Cette seconde table est surveillée par un processus Zapier qui envoit aux freelances un email contenant le lien vers un formulaire AirTable prérempli leur permettant de saisir leur CRA. Les données du formulaire sont alors automatiquement enregistrées dans la table associée au formulaire AirTable.

En résumé et d’un point vue architectural, nous laissons la logique applicative à AirTable (i.e. constituer la liste des freelances qui doivent remplir leur CRA) et la logique d’interfaçage technique/intégration à Zapier (i.e. un nouvel enregistrement dans une table déclenche l’envoi d'un nouvel email).

Intégration AirTable et Zapier; Source

Note : Zapier ? Qu’est-ce donc ? Une offre de services (en SaaS) qui permet d’intégrer entre elles des applications web de manière automatisée dans un workflow commun. Le workflow est constitué de “Zap”, flux de travail automatisé qui connecte les applications et services entre eux. Chaque “Zap” se compose d'un déclencheur et d'une ou plusieurs tâches. Lorsque le “Zap” est activé, il exécute les tâches à chaque fois que l'événement déclencheur (trigger) se produit. Dans notre cas le déclencheur est la création d’un enregistrement dans une table AirTable, la tâche est l’envoi d’un email.

Est-ce-que c'est fait pour moi ?

Avant de se lancer, certains prérequis sont bons à connaître pour éviter les déceptions/désillusions et surtout les blocages.

Le contexte reste celui d’équipes qui n’ont pas ou peu de ressources IT à disposition avec en particulier un budget IT qui reste en dessous des radars de ce que gère une DSI habituellement en projet. Cette équipe souhaite développer une application pour elle-même ou pour un nombre réduit d’utilisateurs.

Corollaire de ces deux points, la DSI n’a que peu de ressources à allouer sur ce type de projet qui sera systématiquement dépriorisé si elle devait l’intégrer dans son portefeuille déjà bien rempli. L’attention qu’elle voudrait bien y porter est négligeable.

Est-ce que c’est fait pour moi ? ; Source

RH / Compétences

Pour modéliser une application de gestion qui dépasse les 8 ou 10 tables avec des relations entre elles puis construire les premières versions (“bootstrap”), mieux vaut avoir des compétences en design/modélisation d'application (ex. UML, Merise). La charge n'est pas excessive (voir chapitre coûts) et faire appel à un développeur, en prestation par exemple sur quelques jours permet d'accélérer et d'éviter les chausse-trapes. D'une manière générale, pour les évolutions, mieux vaut maîtriser le design de son modèle de données afin de l'implémenter correctement au travers des paramétrages AirTable.

Point d’attention : "la courbe d'apprentissage de l'outil AirTable est longue pour les utilisateurs sans culture base de données".

Par ailleurs, nous avons utilisé le Scripting Block qui permet d’automatiser des tâches par l’écriture de scripts JavaScript qui interagissent avec les données de AirTable. Ce Scripting Block est une des nombreuses extensions qu’il est possible d’ajouter à AirTable et qui sont connues sous le nom de Blocks. De nombreux Blocks sont disponibles et il est même possible de développer ses propres blocks au travers d’un SDK  orienté développeur. Ce n’est pas la voie que nous avons choisie, nous nous sommes limités à utiliser le Scripting Block fourni par AirTable.

L’utilisation de la fonctionnalité de Scripting Block permet d’implémenter des processus internes à AirTable de manière fiable, rapide et économique.

Vue générale Scripting block; Src

En termes de compétences, cela nécessite d’avoir quelques connaissances en JavaScript. Le ticket d’entrée n’est pas élevé et en accédant à cet aspect d’AirTable, vous entrez dans le monde du low-code. Là encore, si vous n’avez pas sous la main un développeur avec quelques jours de prestation, vous pouvez vous en sortir assez aisément. Le niveau d’expertise exigé n’est pas élevé.

No-Code ou Low-Code finalement ?

Zapier a été utilisé pour déclencher un envoi d’email lorsqu’une ligne est créée dans AirTable. La définition du Zap, qui comprend un trigger (nouvel enregistrement dans AirTable) et une tâche (envoi d’email) est guidée par les assistants de l’interface graphique de Zapier. La prise en main est aisée.

Note : Il est possible de le faire directement depuis AirTable. La façon de paramétrer ressemble beaucoup à celle de Zapier. En revanche, l’email est envoyé depuis un compte AirTable, l’intégration est donc moins bonne que depuis Zapier qui permet un envoi d’email depuis un compte personnalisé. Automations (Currently available on Enterprise).

Niveaux d’expertise attendus pour chaque outil dans notre cas d’usage

La gestion du changement

Qui dit nouvel outil, dit gestion du changement. Avant de se lancer sur un nouvel outil, il est recommandé d’explorer ceux que l’on ‘maîtrise’ et en particulier dans notre cas, l’équipe a pris le temps de prototyper de son côté sur la base des outils en leur possession à savoir ici GSheet. Durant cette exploration, l’équipe a en particulier découvert une fonction qu’elle n’exploitait pas jusqu’alors : QUERY.

Note : QUERY est une fonction de GSheets qui permet de renvoyer les données répondant à une ou plusieurs conditions, de grouper, trier, filtrer, pivoter, formater des données, de traiter des dates et des heures, de calculer des sommes, moyennes, maximums, …). La fonction QUERY exécute une requête sur toutes les données d'une plage et retourne un tableau de données. Les requêtes sont écrites dans un langage très similaire au SQL.

L’équipe possède 2 personnes maîtrisant GSheet et 1 personne maîtrisant l’univers SQL. C’est un avantage pour elle, aucune acquisition de compétences même minime n’est requise de son côté. Finalement, nous sommes bien dans un univers low-code …. mais que l’équipe maîtrise.

Par ailleurs, la suite Google fait partie des outils supportés par notre DSI; AirTable non. Certes, il ne faut pas fermer la porte au “shadow IT” pour expérimenter et tester, mais pour une application opérationnelle de gestion, c’était un argument supplémentaire pour l’équipe et ainsi rester sur GSheet.

L’utilisation de GSheet comme coeur de l’application permet aussi de rester très ouvert sur les futurs besoins car de nombreux outils no-code peuvent utiliser les données de type GSheet. Par exemple avec Glide ou AppSheet (acquis par Google) il est possible de construire en no-code une application mobile qui permet de visualiser les freelances ou les projets en activité directement depuis son mobile.

A ce stade, l’équipe teste en autonomie une refonte sur la base des mêmes outils en sa possession. Rendez vous d’ici quelques semaines pour comparer plus précisément les 2 approches.

Il est fondamental de laisser l’équipe mettre dans la balance de son choix, les outils à sa disposition et les compétences qui lui sont nécessaires pour développer en no-code ou low-code. Au-delà des gains ou des inconvénients des outils, l'appropriation et la maîtrise par l’équipe est la condition sine qua non de la réussite du projet.

Le modèle de licence logiciel

AirTable facture globalement à l’utilisateur authentifié. Le tableau suivant présente une  synthèse de l’adéquation des usages de AirTable par rapport au coût des licenses.

Adéquation d’une solution no-code facturée à l’utilisateur suivant les cas d’usage

Avec Zapier nous n’avons qu’un seul processus à automatiser une fois par mois (i.e. envoi de quelques centaines d’emails une fois par mois). Dans le modèle de Zapier nous constatons que la facture monte vite si beaucoup de tâches au sens Zapier sont activées (voir point de vigilance). Arriver à plusieurs milliers de tâches par mois est assez rapide. Le coût s’exprime alors en plusieurs centaines de dollars. 
Quelques ordres de grandeur : 5000 tâches (89$/mois); 20 000 (189$/mois); 50 000 (300$/mois). Au-delà de 200.000 tâches par mois, le coût s’exprime en milliers de dollars par mois (https://zapier.com/pricing).

Point de vigilance : Une tâche est comptée chaque fois qu'un Zap réussit à déplacer des données ou à agir à notre place (i.e. règles de gestion, clauses conditionnelles en succès - if, then, else -,…). Par exemple, si un Zap a une tâche pour créer de nouveaux contacts Google, chaque contact créé utilisera une tâche. Le nombre de tâches dépend du nombre de Zaps actifs et de la fréquence à laquelle ils seront exécutés. Tout ce qui intègre de l'algorithmie, du filtrage, des règles de gestion, … sera de préférence externalisé en amont, en préparation des données avant l’usage / appel à Zapier.

L’optimisation des coûts induits par Zapier passe par l’optimisation du design des étapes (nombre de Zaps exécutés) et par l’optimisation du nombre d'occurrences sur lesquelles les Zaps seront exécutés.

Support

Pour Zapier et AirTable, la documentation est fournie, variée et riche….mais exclusivement en anglais. Les communautés de pratiques nombreuses et actives sont elles aussi essentiellement anglophones.

Sécurité

La communication entre les applications AirTable avec les serveurs AirTable, passe sur un canal protégé par un cryptage TLS 256 bits. Au niveau du stockage, AirTable crypte les données en utilisant AES-256.

Les serveurs AWS (Amazon Web Service) AirTable sont situés aux États-Unis, dans des centres de données certifiés SOC 1, SOC 2 et ISO 27001 (https://airtable.com/security).

Zapier est aussi hébergée sur AWS et s’appuie sur les mêmes types de protocoles qu’AirTable (https://zapier.com/help/account/data-management/security).

Résilience

AirTable utilise une infrastructure d'hébergement Amazon Web Services (AWS). Les sauvegardes sont répliquées de manière géo-redondante sur plusieurs zones de disponibilité. AirTable maintient des plans de continuité d’activités (PCA) et de reprises après sinistre (PRA).

Les composants du plan de reprise après sinistre comprennent plusieurs scénarios qui sont régulièrement revus et répétés. AirTable met en œuvre une surveillance étendue du service - 24x7x365 (https://airtable.com/security).

Résilience; Src

Intégration par API

L'API d’AirTable est limitée à 5 requêtes par seconde par base. Si ce taux est dépassé, une erreur est levée et il faut attendre 30 secondes avant que les demandes suivantes aboutissent. Si un volume de lecture plus élevé est anticipé, il est alors recommandé d'utiliser un proxy de mise en cache. Si on voulait utiliser un tel outil sans trop de développement IT complémentaire et externe, on doit alors s'interroger sur la pertinence d'AirTable dans un tel cas d'usage.

Les coûts

Pour vous donner un ordre de grandeur voici ce que nous a coûté (en temps et en licence) le développement d’une telle application sur la base de personnes avec un background en informatique et une expérience modérée sur les outils AirTable ou Zapier.

Phase initiale, la V1

• 3j.hommes de prise de contextes et de modélisation/conception
• 2j.hommes de développement sous AirTable
• 2h de démo et prise de feedbacks auprès de l’équipe opérationnelle
• 1/2j.homme de tests et de prise en main par les opérationnels

2e Phase, la V2

• 1j.homme : conception et développement d’un script pour peupler une table sous condition (assimilable à un trigger), ce travail est l’étape indispensable à la préparation des données avant l’automatisation d’envoi d’email à partir d’un process Zapier.
• 1j.homme : de prise en mains et de configuration d’un processus Zapier pour l’envoi automatique d’un email contenant un lien vers un formulaire AirTable

Licence

Quelle licence et pour quoi faire; Src

La version AirTable choisie est la version “PRO” qui inclut un nombre illimité de bases avec 50.000 lignes par base et 20 Go de stockage chacune. Son coût est de 20$ par utilisateur et par mois (base annuelle). Elle inclut des fonctionnalités supplémentaires dont nous avons eu besoin comme l’accès aux BLOCKS qui permettent via quelques lignes de code simples (scripting) d’accéder à des fonctionnalités avancées inaccessibles via les interfaces standard (voir chapitre “Est-ce que c’est fait pour moi ?”).

La version "FREE” qui inclut un nombre illimité de bases avec 1.200 lignes par base et 2Go de stockage chacune est limitée fonctionnellement. Par ailleurs, le nombre de 1000 lignes est rapidement atteint lorsque l’on parle d’une application opérationnelle. Elle est uniquement adaptée pour tester le produit.

La version intermédiaire est la version “PLUS” qui a les mêmes limitations fonctionnelles que la version “FREE”, mais qui inclut un nombre illimité de bases avec 5.000 lignes par base et 5Go de stockage chacune : 10$ par utilisateur et par mois sur une base d’une cotisation annuelle. C’est une version qui aurait pu nous satisfaire d’un point de vue volume si nous n’avions pas eu besoin de faire appel aux fonctionnalités des BLOCKS. Enfin, une version entreprise est adaptée dans le cas d’un accord entreprise avec AirTable (https://airtable.com/pricing).

La version de Zapier choisie est la version “Starter” qui inclut 20 Zaps, le développement de processus multi étapes et l’exécution de 750 tâches / mois.

Il existe 5 niveaux de licence Zapier. Cela va de l’usage pour la découverte (free) à l’usage extensif en entreprise (“company”). En intermédiaire, un panel de prix qui peuvent se moduler et qui varient fortement selon le nombre de tâches à exécuter chaque mois. La modularité tarifaire permet de choisir par palier progressif une offre adaptée à la quantité de tâches à exécuter par mois.

Les gains / avantages

Dans notre cas d’un développement d’une application de gestion dans le contexte mentionné au début, nous bénéficions d’une approche orientée données couplée à la solution AirTable et dans une moindre mesure Zapier.

Les gains et avantages; Src : PurePeople

Architecture des données

En modélisant et en structurant les données/objets manipulées nous avons posé un modèle et des éléments de contrôles d'intégrité. Ces derniers sont implémentés pour parties dans l’outil AirTable.

Nous aboutissons finalement à une modélisation des données évolutive et implémentée dans un outil orienté données structurées.

Déploiement

AirTable et Zapier offrent des solutions SaaS sécurisées immédiatement accessibles, le déploiement est sans douleur et transparent dans un cloud.

RH

Le résultat réside aussi dans l’autonomie qu’ont les équipes opérationnelles dans la maîtrise des évolutions sur leur application. Ils ont la possibilité de diriger eux-mêmes des d'évolutions simples sur la gestion des données, leur agrégation ou leur tri.

UX

AirTable est un outil à l'interface simple ne nécessitant pas de compétences SQL pour requêter, agréger et filtrer des données structurées. Des sous-jacents SQL (ex. JOIN) sont exploités de manière transparente pour l'utilisateur final, ce qui lui facilite la vie. Pour les néophytes, l’outil est globalement plus simple qu'une feuille Excel ou GSheet avec la possibilité de construire des champs calculés, faire rapidement des tris, construire des vues sans dupliquer les données dans des onglets multiples (comme dans une feuille Excel). Les mauvaises manipulations sont contrecarrées par des moyens simples pour restaurer des données effacées (niveau enregistrements, tables, vues ou bases).

L’outil permet facilement de gérer des données référentielles dans des tables/onglets dédiés. Une autre simplification pour l’utilisateur final réside dans la possibilité de passer par des interfaces de type formulaires pour ajouter des données en incluant en cascade les entités liées.

Enfin, les opérationnels nous ont remonté que la vue calendrier était un plus pour leur suivi et le renouvellement de contrats des freelances arrivant à expiration.

AirTable est un outil à l'interface simple ne nécessitant pas de compétences SQL pour requêter, agréger et filtrer des données structurées; Src

Intégration processus existant

Nous avons pu réaliser, grâce à un “scripting block” et un processus Zapier, l’envoi par email d’un formulaire prérempli lié aux CRAs des freelances et intégrer automatiquement leur retour par remplissage automatique dans la solution AirTable.

Nous pouvons importer des feuilles Excel sous format CSV et réaliser des exports de données filtrées au même format.

Support

Les exemples, modèles et aides autour des solutions sont nombreuses. Nous avons pu accéder à une documentation en ligne fournie, des webinars… Nous avons trouvé assez vite des réponses à nos questions, les communautés de pratiques étant actives et nombreuses.

Les coûts

20$ / utilisateurs authentifiés / mois en version “PRO” d’AirTable et 20$ / mois dans la version starter de Zapier. Dans notre contexte, les coûts de licences cumulés restent extrêmement raisonnables (voir chapitre “Est-ce que c’est fait pour moi ?”****).

Dans notre cas l’offre “Starter” a été suffisante à 20 $ / mois. Le coût de Zapier peut rester maîtrisable si on prend soin de gérer les règles de gestion (règles métier, filtres, condition d'exécution de tâches,..) le plus en amont possible avant de confier une intégration / exécution à Zapier. D’une manière générale, on peut considérer que l’offre “Professional” de Zapier est vite atteinte, auquel cas il faudra débourser environ 100 $ / mois.

Les coûts de développement et d’intégration restent faibles, y compris en faisant appel à de la prestation externe. Dans les problématiques que nous avons rencontrées, quelques jours de prestation suffisent aux développements des demandes qui ne nécessitent pas une expertise forte (conception/modélisation d’application de taille modeste < 10 tables, un peu de programmation JavaScript).

Les coûts de licences cumulés restent extrêmement raisonnable et les coûts de développement et d’intégration restent faibles
Src : https://shop.spreadshirt.fr/mygeekshirt/

Et après - l’évolutivité

En termes d’intégration, il existe des possibilités d'automatisation et d'intégration dans un SI via les BLOCKS, l'API propre d'AirTable ou/et l'outil Zapier.
L’API d’AirTable suit de près la sémantique REST, utilise JSON pour coder les objets et s'appuie sur les standards HTTP pour les résultats des appels. La documentation de l'API de son application AirTable est générée automatiquement.

Point d’attention : modifier le nom ou le type d'un champ (colonne) et l'interface API de ces champs changera en conséquence. Il faut veiller à mettre à jour son implémentation API chaque fois que des modifications sont apportées aux schémas AirTable depuis l'interface graphique. Il existe une API officielle - client en JavaScript: airtable.js (Node.js + browser) et une API construite par des communautés - client : Ruby: airrecord; .NET: airtable.net.

Rappel: AirTable BLOCKS est une plate-forme qui vous permet d'ajouter des mini-applications (blocks) sur votre base pour étendre davantage ses capacités. Elle est uniquement disponible sur les offres Pro et Entreprise (voir chapitre “Est-ce que c’est fait pour moi ?”).

Les limites rencontrées

Si vous pensez que l’outil reste effectivement accessible pour vous alors voici les limites que nous estimons “non bloquantes” que nous avons rencontrées.

Les limites rencontrées; Src

RH / Compétences

Certaines fonctionnalités que les gens peuvent connaître dans Excel ou GSheet ne fonctionnent pas de la même manière dans AirTable. Il y a un temps d’adaptation pour entrer dans la logique d’AirTable.

UX

• AirTable n'a pas de “back-end” ni de “front-end”, c'est une sorte de "mid-end".  Pour les applications riches (tables, règles de gestion) ou orientées processus on ne peut créer des écrans de processus front “user friendly” sauf à passer par le développement de blocks. Si tel est le cas, on peut s’interroger légitimement sur l’adéquation d’AirTable à ce type de besoin ;-)
• Les formulaires peuvent uniquement créer de nouveaux enregistrements. La mise à jour d'enregistrements existants est impossible.
• Des limitations sur la localisation, en particulier l’utilisation obligatoire du point pour le séparateur décimal.

Architecture

• Les clés primaires sont invisibles, gérées par AirTable en arrière plan. Elles ne sont pas nativement portées par des champs fonctionnels. Pour avoir un contrôle d’intégrité, il faut le gérer soi-même par le design et par le paramétrage des relations entre tables. Il faut gérer les relations entre les tables en spécifiant le sens de la relation et la cardinalité attendue.
• AirTable ne permet pas de créer des vues à partir de rien, une table doit exister au préalable.
• Il y a une incapacité à relier les données d'une base à des données d'une autre base - bases de données interrelationnelles.
• On ne peut créer nativement des triggers sur les tables (le contournement passe par l’écriture de “scripting blocks”).
• Nativement, l'outil ne permet pas de naviguer à l’envers une relation d’une table sur elle-même. Par exemple, si dans une table contenant les personnes on définit une relation “ a pour père” il est possible à partir d’une personne de trouver son père, en revanche l’outil ne permet pas de trouver directement les fils liés à une personne donnée (le contournement passe par la création de scripts via les  “scripting blocks).
• AirTable est structuré en ‘Onglet’ qui s'appuie sur des notions de tables + relations & vues (données venant d'autres tables). On arrive vite à avoir besoin de faire de nombreuses imbrications en cascade d'onglets ("vue dans des vues") en mode poupées russes. En établissant une relation entre deux onglets (père & fils), on hérite bien des champs de l'onglet fils, mais on ne peut rajouter des champs du 3e niveau - petit fils qui ne seraient déjà hérités au niveau du fils (voir schéma ci-dessous). La jointure ne peut se faire que sur un seul niveau.

Structuration et héritage des données entre tables/vues/onglets dans AirTable

Sécurité

Sur AirTable, on ne peut créer d'habilitations fines au niveau des tables ou des champs.

Conclusion

En bilan positif

• AirTable est un outil orienté données structurées qui permet bien d’implémenter une application de gestion
• L’équipe opérationnelle a été rapidement autonome dans la maîtrise des évolutions simples sur leur application
• AirTable est un outil à l'interface simple ne nécessitant pas de compétences SQL pour requêter, agréger et filtrer des données structurées
• AirTable et Zapier sont des solutions SaaS immédiatement accessibles, le déploiement est sans douleur et transparent dans un cloud résilient et sécurisé (AWS)
• Les exemples, modèles et aides autour de deux solutions sont nombreuses et efficaces;  les communautés de pratiques sont actives et nombreuses
• Grâce à la fonctionnalité des “scripting block” d’AirTable et des processus Zapier, on peut recréer des processus automatisés de manière efficace
• Pour des applications de gestion à destination de petites équipes internes (10 à 20 utilisateurs authentifiés), les coûts de licences cumulés restent extrêmement raisonnables. Les coûts de développement et d’intégration restent faibles, y compris en faisant appel à de la prestation externe. L’optimisation des coûts induits par Zapier passe par l’optimisation du design des étapes à processer et par l’optimisation du nombre d'occurrences sur lesquelles les Zaps seront exécutés.

Ok mais, alors no-code ou low-code ? A ce stade avec AirTable, notre conclusion serait que dans le cas d’une application de gestion, on aboutit assez vite à devoir faire du low-code pour combler / compléter des fonctionnalités dont nous avons définitivement besoin en particulier pour assurer des processus ou quelques règles de gestion même simples. Dans ce cadre, voici nos recommandations.

Nos recommandations

Nos recommandations; Src : https://www.irishtimes.com/life-and-style/health-family/gossip-can-be-hazardous-to-your-health-1.2939967

Nos recommandations “compétences / RH”

En termes de compétences et ce dès la conception, développer une application de gestion sous AirTable fera appel à des notions élémentaires de conception, d’architecture, ou de langage informatique. Le niveau reste toutefois modeste et nous conseillerions de ne pas rechigner à investir quelques jours en prestation si vous ne disposez pas de ressources en interne. C’est un investissement modeste qui vous fera partir du bon pied et vous fera monter en compétence par la même occasion. Dans notre cas un profil idéal serait un informaticien sachant modéliser les tables / objets d’une petite application (<10 tables) et ayant quelques connaissance en JavaScript. La prise en main d’AirTable (Zapier) et la montée en compétence sur l’outil n’étant pas un frein pour nous. Connaître ces 2 outils est toutefois un plus.

Alors, les promesses du no-code ne seraient-elles pas tenues?  Est-ce grave ? Non, car comme nous l’avons dit les outils sur leur base no-code offrent déjà de nombreux atouts et l’expertise pour bien s’en servir sont suffisamment répandues et abordables.

Enfin, la gestion du change au niveau de l’équipe et plus largement de l’entreprise est à prendre en compte. Faire entrer un nouvel outil dans l’entreprise n’est pas anodin. Par ailleurs, la suite Google fait partie des outils supportés par notre DSI; AirTable, non. Ce n’est pas rédhibitoire, mais il est fondamental de laisser l’équipe mettre dans la balance de son choix, les outils à sa disposition et les compétences qui lui sont nécessaires pour développer en no-code ou low-code. Au-delà des gains ou des inconvénients des outils, l'appropriation et la maîtrise par l’équipe est une condition sine qua non de la réussite du projet.

Nos recommandations “gouvernance”

Enfin, en termes de gouvernance avec AirTable une approche mixte no-code / low-code satisfaisante serait selon nous d’utiliser les fonctionnalités du scripting que si nécessaire et … sans en abuser.
Pour des soucis de facilité de maintenance nous recommanderions d’adopter une posture d’usage de petits scripts (simples à maintenir) et avec gros gains de productivité. Partez dans l’idée que vous essaierez d’éviter autant que possible : “je fais tout mon possible pour utiliser l’outil tel qu’il est. Je l’adapte ou le fais adapter à la marge par du développement spécifique / à façon.”  De la sorte, je m’assure une maintenance non douloureuse dans la durée. Restez dans l’utilisation des fonctionnalités offertes nativement par l’outil et n’allez vers une approche low-code qu’en dernier recours et pour chercher un gain de productivité maximal.

Pour aller plus loin

Articles blog Octo

• Le boom des outils No-Code avec le confinement | OCTO Talks !
• No-code/low-code : les trois bonnes raisons de s'y mettre | OCTO Talks !
• Outils no-code et low-code : la baguette magique de ceux qui ne codent pas ? | OCTO Talks !
• Quelle place pour le no code/ low code dans les entreprises – Compte rendu du talk de Alain Faure & Laurent Sollier à La Duck Conf 2020 | OCTO Talks !
• Culture Innov' : Osez le code jetable ! | OCTO Talks !
• Le low-code, comment ça marche ? | OCTO Talks !

Formations & outillages

• https://www.octo.academy/fr/formation/376-developper-une-application-sans-savoir-coder
• Conseil et formations sur le no-code pour les entrepreneurs et intrapreneurs https://www.contournement.io/
• Site sur les outils de no-code pour les entrepreneurs/intrapreneurs : https://www.nocoders.fr/

Podcast

d’Alexis de Contournenment.io dans son interview de Charles Thomas (Episode #3 : conversation avec Charles Thomas de Comet.co) sur l’usage du Low/No-code dans la construction de la société Comet (https://www.comet.co/).