Plusieurs outils à la fois doivent entrer dans les questions d'entretien d'un développeur no-code. Le poste assemble une base de données (Airtable, Xano, Supabase), une interface (Bubble, Webflow, Softr, Glide ou WeWeb) et des automatisations (Make, Zapier, n8n) reliées par des API et des webhooks. Les offres demandent aussi un peu de JavaScript pour combler ce que les outils ne font pas.
Un portfolio de prototypes ne suffit pas à juger un profil. Demandez une application ou une automatisation encore en service après plusieurs mois, avec de vrais utilisateurs. La personne qui en a tenu une parle de privacy rules, de workload units qui dérapent, de scénarios relancés sans doublons, de jetons OAuth expirés et de la documentation laissée à l'équipe. Celle qui n'a fait que des démonstrations parle surtout de rapidité.
Listez avant l'entretien les outils réellement en place et le volume traité : quelques centaines de lignes par mois ou des dizaines de milliers. Le PDF contient un cas de 20 minutes sur un portail de demandes d'intervention.
Les outils qu'un développeur no-code relie entre eux
Bubble
L'outil le plus répandu pour construire une application web complète sans code : base de données, pages, workflows, back-end. La facture dépend des workload units consommées par les recherches et les workflows. La sécurité repose sur les privacy rules, que beaucoup de projets oublient.
Webflow
L'outil de construction de sites, avec un CMS pour les contenus répétés (articles, fiches produits) et des animations. Il sert surtout aux sites marketing et aux portails de contenu. Le code personnalisé y reste possible, en blocs embed.
Airtable
Une base de données à l'allure de tableur, avec des tables liées, des vues, des formulaires et des automatisations. Son API est limitée à 5 requêtes par seconde et par base, ce qui pèse sur les synchronisations de gros volumes.
Xano et Supabase
Des back-ends construits sur PostgreSQL, avec une API générée. On y passe quand Airtable ne tient plus le volume ou quand il faut des droits fins sur les données. Supabase s'approche du développement classique, avec du SQL et des règles par ligne.
Make
L'outil d'automatisation visuel le plus courant dans les offres françaises. Un scénario enchaîne des modules (lire un formulaire, créer une ligne, envoyer un e-mail). La facturation se fait en crédits depuis août 2025, en général un crédit par action de module.
Zapier
L'autre grand outil d'automatisation, avec un très large catalogue de connecteurs. Facturé à la tâche, il convient aux enchaînements simples et devient coûteux sur de gros volumes.
n8n
Un outil d'automatisation qu'on peut héberger soi-même, avec des nœuds de code en JavaScript ou Python. Il plaît quand les données doivent rester sur une infrastructure maîtrisée. Sa licence, la Sustainable Use License, encadre l'usage commercial.
Softr, Glide et WeWeb
Des outils d'interface branchés sur une base existante (Airtable, Xano, Supabase) pour monter un portail client ou une application mobile interne. Ils vont vite, mais les droits d'accès se règlent outil par outil.
Le développeur no-code travaille souvent seul ou dans une petite équipe, au plus près des utilisateurs, et passe d'un outil à l'autre dans la même journée. Les alternances et les postes juniors portent sur Airtable, Make et des applications Bubble ou Glide simples. Les profils confirmés conçoivent des applications utilisées au quotidien, avec un back-end séparé et des intégrations par API. Il n'existe pas de certification de référence commune à ces outils : le jugement se fait sur des réalisations en service et sur la manière dont la personne parle de sécurité, de coûts et de maintenance.
Les compétences no-code à noter en entretien
- Modélisation de données relationnelles
- Workflows et performance Bubble
- Automatisations Make, Zapier et n8n
- API, webhooks et OAuth
- Sécurité des données et RGPD
- Coûts, limites et maintenabilité
Cinq situations pour juger un développeur no-code
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Dans une application Bubble, comment empêchez-vous un utilisateur de lire les données d'un autre ?
Une bonne réponseDes privacy rules sur chaque data type, appliquées par le serveur avant l'envoi des données : seul le créateur, ou les membres de la même organisation, voit les champs et trouve les enregistrements dans les recherches. Cacher un groupe ne protège rien, les données arrivent quand même dans le navigateur. La personne règle le mode de confidentialité des recherches sur Strict pour une application sensible et réserve l'option qui ignore les privacy rules à quelques backend workflows maîtrisés.
Signal d'alerteUne condition de visibilité sur les groupes, ou des privacy rules laissées sur « tout le monde voit tout ».
Question 2 · confirmé
Un scénario Make s'arrête au milieu : la moitié des factures sont créées. Comment évitez-vous les doublons au passage suivant ?
Une bonne réponseUn gestionnaire d'erreur sur le module qui échoue : Break pour stocker l'exécution incomplète et la relancer, Resume ou Ignore selon le cas, Rollback quand les modules le permettent. Avant chaque création, une recherche par identifiant externe (numéro de commande) ou un data store qui garde les identifiants déjà traités, pour que le passage suivant ne recrée pas les factures. Une alerte part vers l'équipe à chaque échec.
Signal d'alerteRelancer le scénario entier à la main en espérant que rien ne se double.
Question 3 · junior à confirmé
Une base Airtable n'a qu'une table de 40 colonnes, avec le nom et l'adresse du client recopiés sur chaque commande. Que proposez-vous ?
Une bonne réponseSéparer les clients et les commandes dans deux tables reliées par un champ de liaison (linked record), puis afficher l'adresse dans les commandes par un lookup et les totaux par client par un rollup. Un champ principal lisible dans chaque table, des listes de choix (single select) pour les statuts. La personne explique qu'une adresse corrigée une fois se corrige partout.
Signal d'alerteGarder la table unique « parce que c'est plus simple à filtrer », ou dupliquer encore les colonnes pour chaque nouveau besoin.
Question 4 · confirmé
Un webhook public crée un compte client à chaque appel. Comment le protégez-vous ?
Une bonne réponseUn secret partagé ou une signature (souvent HMAC) vérifiée à chaque appel, un contrôle du contenu reçu avant toute écriture, une restriction par adresse IP si l'émetteur la permet et une limite de débit. L'appel porte un identifiant unique pour ne pas créer deux comptes. La personne ne met jamais l'URL du webhook ni une clé d'API dans le code visible d'une page Webflow ou Bubble.
Signal d'alerteUne URL de webhook considérée comme secrète parce qu'elle est longue, et appelée depuis le JavaScript du site.
Question 5 · confirmé
Une application Bubble consomme deux fois plus de workload units que prévu ce mois-ci. Que regardez-vous ?
Une bonne réponseLe détail de la consommation dans les journaux de l'application, par page, workflow et type d'activité. Les causes fréquentes : des recherches lancées au chargement et répétées dans des groupes imbriqués, des recherches larges filtrées ensuite côté navigateur au lieu de contraintes dans la recherche, des workflows récurrents ou planifiés trop souvent, un plugin qui interroge une API en boucle. La personne corrige la page la plus coûteuse avant de changer d'offre.
Signal d'alerte« On passe à l'offre supérieure », sans ouvrir le suivi de consommation.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Questions fréquentes sur le recrutement no-code
Développeur no-code ou développeur low-code : quelle différence pour le recrutement ?
Le développeur no-code travaille avec des outils grand public (Bubble, Webflow, Airtable, Make) et livre vite des applications et des automatisations pour une équipe. Le développeur low-code travaille sur des plateformes d'entreprise comme Power Platform, Mendix ou OutSystems, avec des environnements, une chaîne de livraison et souvent du code en complément. Les compétences se recoupent sur la modélisation et les API. La gouvernance et l'outillage de livraison diffèrent beaucoup.
Quelle part de code attendre d'un développeur no-code ?
Une petite part, qui se vérifie. Les offres demandent souvent du JavaScript pour un script, un calcul ou un composant que l'outil ne propose pas, et la lecture d'une documentation d'API (méthodes, en-têtes, codes d'erreur, JSON) revient à chaque intégration. Une personne qui ne sait pas lire une réponse JSON ou interpréter une erreur 401 restera bloquée à la première intégration. Le SQL devient utile dès qu'un back-end PostgreSQL entre en jeu.
Quelle mise en situation donner à un développeur no-code ?
Un test technique d'une heure sur les outils du poste : un formulaire qui alimente une base Airtable par Make, avec un cas d'erreur à gérer et une règle d'accès à poser. Faites-le en direct, partage d'écran ouvert, et demandez à la personne d'expliquer ses choix. Ajoutez une question sur le coût du scénario à 10 000 exécutions par mois. Vous voyez la méthode, pas seulement le résultat.
Comment juger un portfolio de développeur no-code ?
Demandez ce qui tourne encore, depuis combien de temps et pour combien d'utilisateurs. Faites ouvrir une application et montrer ses privacy rules ou ses droits d'accès, un scénario et son historique d'erreurs, la documentation laissée au client. Un beau prototype montre un sens du produit. Une application en service depuis un an, avec ses incidents racontés précisément, montre le métier.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
