Le No code offre aux entreprises de multiples leviers d’innovation produit ou d’automatisations de process métier. Pourtant acquérir cette nouvelle compétence de delivery (complémentaire à celle des développeurs, data analytics/scientists, etc.) pour une scale-up ne se fait pas sans difficulté.
Chez Gojob, le No code est désormais partie intégrante du produit grâce à nos 3 No codeurs spécialisés (+2 prévus par an), 200+ scénarios Make (ex-Integromat) actifs, 1,5 millions d’opérations mensuelles, 10 portails clients/internes, 20 logs d’erreurs hebdomadaires, etc.
Recrutement, stack technique, standards de développement no code, organisation et fonctionnement en équipe : nous vous partageons 5 retours d’expérience sur la création d’une équipe No code dans une scale-up.
1- Recruter des Product Builders, experts du produit, du No code et de la Data
Lors des phases de recrutements, nous recherchons des profils couplant des compétences Product, Maker et Data (voir notre article dédié aux compétences clé des Product Builders). Sur le volet Maker, nous cherchons un spécialiste mais préférons un candidat qui maîtrise plusieurs outils No code en profondeur qu’un expert d’un seul outil (par exemple Bubble). Les compétences axées tech/data ne sont pas requises mais sont valorisées, notamment sur l’API, les interconnexions avec des bases de données (PostgreSQL, Google Big Query). En effet, en scale-up, il est clé d’interconnecter le no code avec le back-end existant pour interagir avec une donnée métier unique et centralisée.
Notre processus de sélection des No codeurs candidats s’échelonne en trois étapes principales, un entretien de motivation RH, un entretien d’intro/compétences avec le head of No code et un cas pratique. Le cas pratique se décline en trois phases, chacune avec un objectif d’évaluation bien ciblé : Une phase de conception pour tester l'esprit analytique (sans les compétences de maker), Une phase de réalisation pour tester le No code pratique sur base de Integromat/Airtable Une phase de transmission pour tester la sensibilité plus axée Product
2- Aligner la stack No code avec les enjeux à adresser
Nous intégrons 5 maillons dans notre stack No code, choisis en fonction des enjeux que nous souhaitons adresser dans notre scale-up : (1) développer des innovations clients ou internes et (2) automatiser des processus métier.
Le premier maillon de notre stack est tout simplement … la stack existante de notre produit Gojob, car en scale-up une grande partie de notre produit n’est pas conçue en No code mais en dev/data. L’un de nos enjeux est donc de savoir interagir avec notre produit, via API, ou directement aux données via PostgreSQL (pour interroger directement les bases de données) ou Google BigQuery (pour interroger notre DataWarehouse mis en place par les équipes de Data Analytics).
Sur certains projets No code, nous implémentons un backend dédié, par exemple pour manipuler des données spécifiques aux solutions No code ou bien pour fournir des outils de reporting : nous utilisons alors principalement Airtable ou Google Sheet.
L’une des forces du No code est son ouverture sur l’écosystème de solutions externes, ainsi la stack no code comprend également tous les plug-ins auxquels nous nous interconnectons. Plusieurs milliers existent et le choix dépend principalement du besoin fonctionnel recherché par les solutions No code. Chez Gojob ? La suite Google et Slack (car déjà dans les mains de nos utilisateurs internes) pour les communications ou transferts de fichiers, Typeform (pour les formulaires), Twilio Studio et MessageBird (pour les communications externes conversationnelles), etc.
Pour nos solutions No code qui s’appuient sur un portail utilisateur interne ou externe, nous utilisons deux type d’outils No code : Les “front” simples et rapides à mettre en place, qui partent d’un back-end existant (par exemple Stacker ou Mini-Extension qui s’appuient sur Airtable) pour des portails internes ou basiques. Les “front” plus évolués via des outils full-stack pour nos portails externes ou plus sophistiqués (par exemple Bubble, que nous utilisons de manière particulière comme un front connecté à Airtable, ou encore Webflow)
Pour finir sur le plus important, le maillon qui fait le liant entre tous les modules précédemment mentionnés : les outils No code d’automatisation. Zapier ? Make (ex-Integromat) ? Parabola ? n8n ? Chez Gojob nous avons fait notre choix : Make. Notamment pour sa capacité à fiabiliser les scénarios via la gestion d’erreur, l’expérience utilisateur (par exemple sur les flows parallèles bien plus performant que Zapier ou le volet intuitif et rapide par rapport à n8n), l’accès à l’API, etc.
3- Appliquer les standards d’excellence pour des solutions fiables et scalables
Même si développer en No code est à la portée de nombreux profils et métiers dans l’entreprise, développer en No code des solutions fiables, scalables et à forte valeur ajoutée reste à la main des experts. C’est pour cela que chez Gojob nous avons décidé de recruter des Product Builders dédiés au No code. Pour accompagner l’excellence de nos développements, nous appliquons des standards lors de chaque phase d’un projet no code.
Lors de la conception, nous assurons scalabilité et fiabilité de nos solutions grâce à un guide de préemption des erreurs (voir notre article dédié au sujet : comment concevoir des solutions No code fiables et scalables) et réalisons systématiquement des revues techniques (“QA”) avec d’autres Product Builders en interne pour valider du bon fonctionnement technique de nos scénarios.
Nous centralisons toute la documentation de nos solutions No code sur Notion (dont les liens sont dans chacun de nos scénarios), permettant à nos Product Builders de se réapproprier simplement les fonctionnements des automatisations.
L’objectif donné à nos Product Builders est de délivrer une solution à impact viable et fonctionnelle davantage qu’un “scénario actif”. Ainsi, nous ajoutons à chacun de nos scénarios un module permettant d’incrémenter nos KPIs métiers sur un Google Sheet dédié. Ceci nous permet de suivre automatiquement et semaine après semaine l’impact métier de nos solutions No code. Ainsi, il est de la responsabilité du Product Builder de s’assurer que la solution No code fonctionne et apporte de la valeur dans le temps.
4- Intégrer l’organisation No code avec l’équipe Produit
Chez Gojob, nos Product Builders sont intégrés dans l’équipe Tech x Produit. Deux objectifs : garantir un alignement entre la delivery No code et les priorités (impliquant une proximité avec l’équipe Produit) et donner tous les leviers à l’excellence technique et à l’interconnexion avec notre back-end existant (impliquant une proximité avec l’équipe Tech).
Le No code est positionné comme une compétence transverse, au même titre que la Data Analytics ou le UX / Design par exemple, et collabore étroitement, selon les sujets, avec nos squads (elles-mêmes constituées de Product Managers et de développeurs).
Même si la priorisation des sujets vient souvent des Head of Product ou Product Managers, nous choisissons de donner des responsabilités aux Product Builders sur les volets “produit” de leurs projets (discovery, delivery, etc.). En effet le No code permettant des itérations plus rapides, laisser responsabilité et proximité avec l’utilisateur final, dans un mode “projet resserré", permet de délivrer de manière plus agile.
5- Industrialiser un fonctionnement d’équipe sur la delivery No code
Pour garantir fiabilité, scalabilité des livrables No code tout en faisant continuellement progresser les Product Builders, il est nécessaire d’implémenter un bon fonctionnement en équipe sur la delivery.
L’utilisation de l’API de Make (ex-Integromat) nous permet de récolter toutes les informations de nos scénarios. Par exemple, extraire les modules unitaires utilisés permet de dresser le “profil” type de chaque No codeur (voir l’illustration ci-dessus) et d’identifier les leviers de progression sur ses scénarios. Similairement, nous avons implémenté un rapport mensuel automatique listant les scénarios à plus forte consommation (en opérations et en transfert de données) afin d’identifier les optimisations potentielles.
Les standards de développement implémentés (modules de gestion d’erreur, QA techniques, etc.) permettent de préempter les erreurs mais nous ne sommes pas pour autant à l’abri de surprises. Ainsi, comment adopter un fonctionnement d’équipe permettant le 100% de fiabilité sur nos livrables ? Le principe : chaque Product Builder garde la responsabilité de la gestion d’erreurs de ses scénarios mais le fonctionnement d’équipe doit permettre à n’importe quel autre No codeur de corriger le problème en autonomie. Les erreurs sont remontées automatiquement sur un Kanban Notion et assignées au concepteur du scénario qui peut ainsi les fiabiliser.
Si vous cherchez à rejoindre l’équipe de Product Managers ou de No coders / Product Builders Gojob, n’hésitez pas à consulter nos offres ici et à nous contacter ou postuler. Si vous souhaitez plus d’informations sur ces bonnes pratiques No code, n’hésitez pas à contacter l’équipe !