Interview : Benoît de Montecler de ncScale

Découvre l’interview de Benoît de Montecler, fondateur de ncScale, startup qui va révolutionner l’usage de nos outils NoCode / LowCode.

‍

“J’ai envie de contribuer à prouver, qu’avec les bonnes méthodes et les bons outils, le NoCode est aussi taillé pour de la production et pas uniquement des MVPs ou des automatisations dans son coin.” - Benoît de Montecler

‍

‍

Est-ce que tu peux te présenter et nous parler de ton parcours ?

Je m’appelle Benoît et je suis entrepreneur depuis l’âge de 16 ans. À l’époque j’ai construit un service d’hébergement web tout en passant mon BAC. Je l’ai monté jusqu’à 500 clients avant de le revendre.

J’ai ensuite rejoint une mutuelle, puis co-fondé digiRocks. Et c’est chez digiRocks en 2018 que j’ai découvert le NoCode en développant l’ensemble de notre ERP sous Bubble.

‍

Pourquoi avoir tout développé en Bubble ?

Chez digiRocks, on n’a trouvé aucun outil du marché à l’époque assez proche de notre besoin et donc pour être au plus proche de celui-ci, on a décidé de tout faire sur-mesure ! J’ai alors découvert à ce moment la puissance de ces outils mais aussi les risques de sécurité inhérents qui peuvent survenir à leur utilisation.

‍

Est-ce que tu peux nous parler de ta boîte actuelle ?

Yes ! En juin 2021, j’ai développé avec mon associé Kévin, nocode:nohack, un outil permettant de vérifier l’aspect sécurité des applications développées sous Bubble. Il y a eu un fort intérêt de la communauté. Tout le monde est tombé des nues sur l’aspect sécurité des plus gros outils NoCode du moment.

‍

D'où venait le problème selon toi ?

Quand je dis sécurité, je ne montre pas du doigt les éditeurs de logiciels NoCode mais plutôt l’usage de ces outils qui n’est pas encore au niveau par la communauté de manière générale sur l’aspect sécurité.

Du coup on a essayé d’éduquer le marché avec la sortie de notre Ebook de sécurité Bubble pour aider aux bonnes pratiques.

‍

Et de fil en aiguille le projet s’est transformé en une vision plus large que la sécurité : fournir à l’écosystème NoCode les outils et méthodes leur permettant de développer de meilleures pratiques, de rendre leurs applications maintenables, documentées, sécurisées et sans bug, notamment via un système d’alerting branché sur les logs.

‍

J’ai envie de contribuer à prouver, qu’avec les bonnes méthodes et les bons outils, que le NoCode est aussi taillé pour de la production et pas uniquement des MVPs ou des automatisations dans son coin. L’idée c’est d’avoir in-fine les mêmes normes de qualité que du code classique.

‍

Est-ce que tu peux m’en dire plus sur le système d’alertes ?

Carrément. Le système d’alerting c’est principalement pour être au courant des soucis sur ton système NoCode en temps réel. Par exemple, dans Bubble il faut aller dans les logs, taper “critical” et lire les logs… Pas très pratique. C’est un peu mieux fait sur Make, mais pas parfait. Notre système d’alerting est un agrégateur des systèmes d’alerting trop basiques (ou inexistant) des outils NoCode.

‍

Pour en revenir un peu sur la sécurité, est-ce que tu penses que c’est un manquement des éditeurs de solutions NoCode ?

Je pense que c’est surtout qu’assommer les utilisateurs avec la sécurité trop tôt aurait abouti in-fine à ce qu’aucun utilisateur n’utilise ses outils. La sécurité est contraignante, presque une douleur et elle tue la productivité.

‍

Si les éditeurs avaient été trop contraignants sur la sécurité, le NoCode n’en serait pas là où il en est aujourd’hui. D’ailleurs le sujet sécurité est plus sur la thématique LowCode, car plus difficile d’accès selon moi.

‍

Tu as quelques exemples en tête sur des problèmes de sécurités ?

Yes, en voici quelques-unes :

• Sur Airtable et Softr, il faut dupliquer les DB pour séparer ce que l’on souhaite mettre en public et en privé.
• En août 2021, Microsoft a eu mauvaise presse car 20 millions de données confidentielles ont fuité sur une App développée sur PowerApps. Le problème venait d’une configuration effectuée par un humain.
• Sur Softr en 2021, une faille a été vue mais corrigée hyper vite.
• Au début de GlideApps, l’ensemble des lignes de la DB étaient préchargées par le navigateur, visibles par tout un chacun. Aucun souci avec ce système s’il a été conçu pour fonctionner tel quel et que les utilisateurs en sont informés. Depuis ils ont rajouté la notion de “Privacy” et changés ce comportement par défaut.

‍

Les éditeurs mettent des avertissements, documentent et forment. Ils ne peuvent pas être tenus responsables des fuites de données, du moins ils se positionnent comme ça. Et on le comprend.

‍

Comment s’est passée ta levée de fonds ?

Alors je ne suis absolument pas expert en levée, je pense que j’avais juste le bon produit au bon moment on va dire.

‍

Voici les étapes de ce qui nous est arrivé :

1. Un Fond m’a approché pour nocode:nohack.
2. J’ai développé la vision pour ne pas être que sur la sécurité mais sur aussi l’alerting, la documentation, le versioning.
3. J’ai postulé à Kima et quelques autres.
4. Kima a dit oui en 2 semaines et nous a mis en relation avec 4-5 autres investisseurs.
5. On a matché avec Elaia très vite et ils m’ont aidé à améliorer mon deck pour le comité d’investissement.
6. On a été validé par le comité.

‍

En vrai, sans le contact entrant du fonds je n’aurais jamais imaginé lever des fonds.

‍

Et Elaia connaissait le monde du NoCode ?

Ils connaissaient très très bien le NoCode, c’est pour ça que ça a matché directement !

‍

Maintenant, quelle est la composition de ton équipe post-levée de fond ?

Alors il y a maintenant, avec Kévin et moi, 6 développeurs. L’équipe technique est pour l’instant au complet et on développe une première version du nouveau produit pour avoir les premiers retours utilisateurs.

‍

On a réussi à recruter l’ensemble de l’équipe Tech en 3 semaines, la folie. C’est grâce à Kévin et son réseau de développeurs.

‍

Comment gères-tu ton développement en interne ?

On a beaucoup de R&D sur chaque outil. On décortique l’ensemble du fonctionnement de chaque outil, c’est vraiment sympa à faire !

Sinon au niveau des devs on a du Front, du Back et un DevOps.

Notre principal enjeu est la scalabilité : on traite énormément de données et du coup on a pensé une architecture hyperpuissante !

‍

Tu recherches d’autres profils ?

Là, je suis en recherche d’une personne pour m’aider sur la partie création de contenu. Le profil est un peu spécial car il doit allier capacité à créer du contenu, rester en veille sur le NoCode et savoir vulgariser de la Tech.

Et on va rechercher aussi bientôt des profils de type Customer Success quand le produit sera prêt.

‍

Et vous êtes tous en remote ?

Oui, 100% remote. Et on a fait notre routine de se voir tous 3 jours par mois avec l’équipe, tous à Lyon. C’est une grosse logistique mais c’est vraiment sympa de le faire. Ça crée du lien !

‍

Ton Business model dans tout ça ?

Je vais itérer dessus ça c’est sûr. On arrivera sans doute à une offre du style : l’outil de “versioning” offert à l’ensemble de la communauté NoCode dans le but de promouvoir des bonnes pratiques. Le reste sera du paiement à l’usage avec un abonnement et des quotas.

‍

Et quelle est ta cible ?

La cible idéale c’est surtout les grands comptes, les Scale Up et les boîtes rentables avec des process critiques en NoCode. Mais toute la communauté pourra bénéficier gratuitement d’une partie des outils ncScale !

‍

Comment es-tu allé chercher tes premiers clients / utilisateurs ?

Sur nocode:nohack, les premiers clients ont été trouvés sur le forum de Bubble. Ça a donné très vite beaucoup d’utilisateurs.

On a également pensé à aller chercher des failles sur les sites des autres pour les prévenir et proposer notre outil, mais ce n’est pas légal de faire du grey-hat. Il faut l’autorisation du propriétaire du site.

‍

L’autre gros canal d’acquisition a été de former les formateurs (des outils NoCode) à la sécurité. On s’est fait citer pas mal de fois grâce à ça.

Et puis sur la sécurité Bubble on est un peu seul, ça a dû jouer grandement !

Ah, et on est dans la documentation officielle de Bubble maintenant aussi.

‍

Est-ce que tu n’as pas peur que tes outils soient implémentés un jour par les outils NoCode eux-mêmes ?

Notre produit sera multi-outils déjà donc on ne sera pas dépendant d’un seul éditeur. On proposera un lieu central regroupant des fonctionnalités que les éditeurs eux-mêmes n’ont pas encore développées (ou ne développeront jamais…).

‍

D’ailleurs certains outils veulent même potentiellement nous confier leur “versioning”, ils n’auraient du coup plus besoin de le développer dans leur éditeur.

‍

Comment vas-tu gérer l’évolution des outils NoCode et leur multiplicité face au langage commun que tu auras créé ?

Cela fait plus d’1 ans que l’on travaille avec ces outils et il y a eu peu de grosses mises à jour. C’est assez rassurant ça pointe dans la direction que notre solution sera maintenable relativement facilement.

‍

Pour finir, est-ce que tu as des conseils pour les lecteurs ?

• Première chose que je trouve importante, c’est de se former. Alors après ça dépendent des tempéraments. Je suis un mauvais exemple sur ce point car j’aime beaucoup expérimenter, tester par moi-même directement. 😅

• Attention aussi à la confiance qui pourrait te prendre après avoir fait un peu de NoCode. Ça a l’air simple, facile, mais en fait il faut bien penser les choses, surtout si tu veux maintenir ton système efficacement ou faire des choses plus complexes. Je me suis fait avoir par ce fameux effet Dunning-Kruger et ça fait mal quand on s’en aperçoit. Ça n’en reste pas moins une révolution.

• Si tu utilises du NoCode pour tester, alors fonce dans le tas, expérimente : il ne faut pas craindre de repartir de zéro pour bâtir encore mieux la version suivante !

‍

En somme, les éditeurs de logiciels NoCode ont fait un super taf pour casser la barrière à l’entrée, mais il y a quand même, surtout sur certains outils, une montée en compétences non négligeable.

‍

Merci Benoît ! Voilà, c’est la fin. Si tu as lu jusque-là tu es fort, il y avait de la matière. Nous avons appris beaucoup de choses grâce Benoît, j’espère que toi aussi !

‍