- SaaS
- Projet
- REX
2 ans et demi comme développeur en startup : retour d'expérience chez ncScale
Pendant environ deux ans et demi, j'ai été développeur JavaScript d'une startup SaaS qui s'attaquait à un problème que personne ne réglait : le monitoring des outils no-code. ncScale récupérait les logs internes de plateformes comme Make, Bubble, Airtable ou Xano pour les analyser, configurer des alertes et détecter les anomalies. Je suis arrivé juste après la levée de fonds, au moment où on reprenait tout de zéro. Voici ce que cette expérience m'a appris, aussi bien techniquement qu'humainement.
Monitorer le no-code : un problème que personne ne réglait
Quand on travaille avec des outils no-code ou low-code, on profite de leur rapidité de mise en place. Mais on perd quelque chose en chemin : la visibilité. Pas de monitoring natif, pas d'alerting digne de ce nom, pas de vue centralisée sur ce qui tourne en production. Si un scénario Make plante à 3h du matin, personne ne le sait avant que le client appelle.
C'est exactement le creux que ncScale cherchait à combler. L'idée : se brancher sur les APIs de ces outils, récupérer leurs logs, les normaliser, et offrir une interface unique pour tout surveiller. Avec en prime un système de notifications configurables, que ce soit par Slack, email ou webhooks. Le produit visait les équipes qui utilisent ces plateformes en production et qui ont besoin de la même rigueur de monitoring no-code qu'avec du code traditionnel.
Les outils supportés couvraient un spectre large : Xano, WeWeb, Airtable, n8n, Bubble, Make, entre autres. Chacun avec ses particularités d'API, ses formats de logs, ses modes de récupération. C'est ce qui rendait le défi technique intéressant, et le produit difficile à répliquer.
De scan de sécurité Bubble à plateforme de monitoring multi-outils
Le tout premier produit ncScale n'avait rien à voir avec le monitoring de logs. C'était un POC de scan de sécurité pour Bubble, capable de détecter des données publiquement accessibles. Utile, mais limité en scope.
Après la levée de fonds, la décision a été prise de tout reprendre from scratch. Le pivot était clair : passer d'un outil mono-usage à une plateforme de log management multi-outils. C'est à ce moment-là que je suis arrivé. Le timing n'était pas anodin. Reprendre un produit de zéro, c'est à la fois excitant (on peut faire les choses bien dès le départ) et intimidant (il n'y a rien, tout est à construire). Quand on rejoint une startup early-stage à ce stade, on ne se contente pas de coder des features. On pose les fondations.
Ce qui m'a marqué, c'est la vitesse à laquelle le scope a grandi. On est passé du scan de sécurité Bubble à une plateforme complète avec listing de logs, filtrage avancé, alerting, asset catalogue, dashboard de statistiques. Le tout en maintenant le support de multiples outils no-code, chacun avec ses spécificités. En tant que développeur en startup, il fallait suivre le rythme.
React dans Symfony, Fastify pour les logs : une stack pensée pour durer
Un choix technique qui surprend souvent quand j'en parle : React embarqué dans Symfony via Webpack Encore. Pourquoi ne pas avoir opté pour un front découplé ? Parce que le backend Symfony existait déjà et qu'on voulait garder la cohérence du monolithe. Le rendu initial des pages passait par Symfony, avec des données injectées directement dans la vue, et une API pour tout ce qui nécessitait de la réactivité côté client.
Côté CSS, on a fait le choix de Tailwind CSS dès le début. Le designer fournissait les maquettes d'un design system complet, et chaque composant devait être développé à la main. Pas de Material UI, pas de Chakra, pas de raccourci. Tailwind nous donnait la flexibilité nécessaire pour coller exactement aux maquettes sans nous battre contre les opinions d'une librairie de composants.
Pour le state management, on a commencé full React Context natif. Ça marchait, mais au fil du temps on a tout migré vers Zustand. Le vrai game changer ? Son système de persist. Plus besoin de sauvegarder chaque donnée en localStorage à la main, tout est géré automatiquement. En quelques lignes, les données étaient cachées localement. L'utilisateur n'attendait plus, tout était déjà là à l'ouverture. Les nouveautés se chargeaient en arrière-plan, sans loader, sans friction.
La recherche et le stockage des logs reposaient sur Elasticsearch. C'était le choix évident pour de la gestion de logs big data : requêtes rapides sur des volumes massifs, agrégations pour les graphiques, filtrage full-text. Le monolithe Symfony interrogeait directement Elasticsearch pour afficher les résultats dans le dashboard.
Un monolithe assumé pour le dashboard, des microservices pour l'ingestion
L'architecture se découpait en deux grandes parties. Le monolithe React / Symfony gérait tout ce que l'utilisateur voyait : le dashboard, l'alerting, l'asset catalogue, les pages de gestion de compte, le pricing. C'était le coeur applicatif.
À côté, deux chemins d'ingestion coexistaient selon les outils. Pour ceux qui exposaient une API, des scripts Node.js déclenchés par cron allaient chercher les logs par polling. Classique, efficace. Pour les outils capables de pousser leurs logs directement, c'est Fastify qui recevait les webhooks. Pourquoi Fastify ? Performance. Quand on reçoit des volumes importants de logs en continu, chaque milliseconde compte.
Dans les deux cas, les logs bruts atterrissaient dans une queue AWS SQS. C'est là que la magie opérait : des scripts Node.js consommaient cette queue et se chargeaient de tout le travail de normalisation. Mise en forme vers le format interne standardisé, enrichissement des données, obfuscation des informations sensibles. Une fois ce traitement terminé, les logs étaient envoyés dans Elasticsearch. SQS jouait un rôle clé de découplage entre l'ingestion et le traitement. Peu importe la source du log, le pipeline de normalisation était le même.
Déduplication, volumes massifs et performance client
La gestion de gros volumes de données était un défi permanent, aussi bien côté backend que côté front.
Côté ingestion, chaque outil no-code avait ses particularités. Make, par exemple, fonctionnait par polling paginé. Le problème : une page de résultats pouvait contenir un mix de logs déjà récupérés et de logs nouveaux. Sans mécanisme de déduplication, on aurait réingéré les mêmes logs en boucle. On a donc mis en place un système de déduplication qui identifiait les logs déjà traités pour ne garder que les nouveaux. Ce genre de détail, invisible pour l'utilisateur, fait toute la différence entre un produit qui tient la charge et un produit qui croule sous les doublons.
Côté front-end, l'enjeu était différent mais tout aussi critique : ne pas surcharger le navigateur. Quand on affiche des milliers de lignes de logs avec des graphiques d'ingestion par minute, heure ou jour, il faut être malin sur ce qu'on envoie au client et comment on le rend. C'est un réflexe que j'ai développé chez ncScale et qui ne m'a jamais quitté : toujours se demander "qu'est-ce qui se passe si cette liste contient 50 000 éléments ?" avant de coder quoi que ce soit.
Posez-vous la question de la performance dès le premier composant si vous savez d'avance que la charge sera élevée, pas quand le client remonte un bug.
Reverse engineering : quand les outils ne jouent pas le jeu
Tous les outils no-code n'avaient pas la gentillesse d'exposer une API documentée pour récupérer les logs. Pour certains, on a dû faire du reverse engineering en équipe : analyser les appels réseau de l'interface, identifier les APIs privées utilisées en interne, et trouver des moyens détournés pour extraire notre donnée. C'est un travail d'investigation que j'ai trouvé passionnant. Ça ressemble plus à du puzzle qu'à du développement classique.
Mais c'était aussi une nécessité produit. La promesse de ncScale, c'était le monitoring multi-outils. Si on ne supportait que les outils avec une API propre et documentée, on passait à côté d'une partie du marché. Alors on a retroussé les manches, on a ouvert les DevTools, et on a trouvé des chemins là où il n'y en avait pas. Ce genre de défi, c'est typiquement ce qu'on rencontre en startup early-stage : le plan A n'existe pas toujours, il faut inventer le plan B.
Construire un SaaS complet quand on est (quasi) seul dev front
Être le principal développeur front-end d'un SaaS complet, c'est une expérience formatrice. Parfois seul, parfois un parmi deux, mais toujours en première ligne. Chaque fonctionnalité passait par moi. Chaque choix d'architecture front, chaque composant, chaque interaction.
Au début, le défi c'est d'être partout. Le backend avance, le designer livre des maquettes, le product owner a des priorités. Et tout le monde attend le front pour que les choses deviennent réelles. Il y a une pression naturelle à vouloir tout faire, tout de suite. On ne peut pas se permettre de bloquer les autres.
Puis avec le temps, le défi évolue. On passe de "être partout" à "prioriser l'important". C'est peut-être la leçon la plus précieuse pour quiconque envisage de travailler en startup early-stage : votre valeur ne se mesure pas au nombre de features que vous livrez, mais à votre capacité à identifier celles qui comptent vraiment. Quand les ressources sont limitées, chaque journée de dev doit avoir un impact.
Un design system from scratch, composant par composant
Pas de Storybook préconfiguré, pas de librairie de composants à importer. Un designer livrait les maquettes du design system, et moi je les transformais en code. Boutons, inputs, cards, modales, drawers, tableaux. Chaque élément d'interface a été construit à la main avec Tailwind CSS.
La décision de ne pas utiliser de librairie de composants externe était délibérée. On voulait un produit qui ait sa propre identité visuelle, pas un énième dashboard qui ressemble à du Material UI par défaut. Le prix à payer, c'est le temps de développement initial. Le bénéfice, c'est un contrôle total sur le rendu et une cohérence visuelle parfaite avec les maquettes.
J'ai fini par structurer tout ça dans une bibliothèque de composants interne avec de la documentation pour les éléments essentiels. Ce n'était pas un Storybook sophistiqué, mais ça permettait à quiconque rejoignait le projet de comprendre les composants disponibles et comment les utiliser.
Créer un design system from scratch prend du temps, mais c'est un investissement qui paie à chaque nouvelle feature. Les composants sont déjà là, prêts à assembler. Et au-delà du gain de vitesse, votre outil gagne sa propre identité visuelle. Reconnaissable immédiatement. C'est du marketing gratuit.
Filtrage SQL, alerting Slack, asset catalogue : les fonctionnalités qui comptaient
Le coeur du produit, c'était le listing de logs. Un tableau avec un graphique d'ingestion (par minute, heure ou jour selon le zoom), et un drawer latéral pleine hauteur qui s'ouvrait au clic sur une ligne pour afficher le détail complet d'un log. Simple en apparence, complexe à réaliser quand les volumes de données sont conséquents.
Le filtrage allait du simple au puissant : des filtres basiques pour les cas courants, et des requêtes SQL pour ceux qui avaient besoin de creuser. Cette dualité était importante. Les utilisateurs techniques voulaient la puissance du SQL, les autres avaient besoin de filtres intuitifs. Il fallait satisfaire les deux.
L'alerting permettait de configurer des notifications sur Slack, par email ou via webhooks, avec des conditions définies par l'utilisateur. C'est le genre de fonctionnalité qui transforme un outil de consultation en outil de travail quotidien. Sans alerting, on consulte les logs quand on y pense. Avec, on est prévenu quand ça compte.
L'asset catalogue offrait une vue d'ensemble sur les ressources des outils connectés : scénarios Make, tables Airtable, etc. Avec un système de drawer multi-onglets et, surtout, une détection des liaisons entre assets. Savoir qu'un scénario Make est lié à telle table Airtable, c'est le genre de visibilité qui manque cruellement quand on opère un stack no-code en production.
Et autour de tout ça, un dashboard d'overview avec les statistiques globales : nombre de logs en mémoire, alertes déclenchées, métriques clés. Plus les pages classiques qu'on retrouve dans tout SaaS : login, gestion de compte, pricing.
Ce que 2 ans et demi en startup early-stage m'ont appris
Côté technique : du front React aux microservices Node.js
En arrivant chez ncScale, j'étais développeur JavaScript. En partant, j'étais développeur JavaScript fullstack avec une expérience concrète en gestion de données massives.
Le front React m'a appris à penser performance dès la conception. Pas en théorie, en pratique, parce que les utilisateurs chargeaient des volumes de logs qui mettaient le navigateur à genoux si on ne faisait pas attention. Les microservices Node.js / Fastify m'ont donné une vision complète de la chaîne : de l'ingestion du log brut jusqu'à son affichage dans le dashboard. Et le travail avec Elasticsearch m'a ouvert les yeux sur ce que signifie vraiment la recherche à grande échelle sur des logs Elasticsearch.
L'infrastructure AWS, notamment SQS, m'a appris l'importance du découplage. Quand on construit un système qui ingère des données en continu, la capacité à absorber les pics sans perdre de données, c'est ce qui sépare un MVP d'un produit fiable.
Avoir touché à chaque couche de la stack m'a rendu bien meilleur sur chacune d'elles. Comprendre comment le backend traite les données change la façon dont on conçoit le front qui les affiche.
Côté humain : bien plus que du code
Travailler en startup early-stage, c'est une expérience qui déborde largement du cadre technique. Avec une équipe qui a compté jusqu'à une quinzaine de personnes au plus haut, tout le monde porte plusieurs casquettes.
J'ai participé à l'élaboration de la stack technique complète. J'ai été impliqué dans des discussions sur le branding, jusqu'au choix du logo. J'ai contribué aux décisions produit, pas juste à leur implémentation. Ce genre d'implication, on ne l'a pas dans une boîte de 500 personnes. C'est ce qui rend l'expérience startup si formatrice.
Mais l'apprentissage le plus important, c'est peut-être celui-ci : mettre le client au centre. En startup, le retour d'expérience développeur ne se limite pas au code. Le retour utilisateur n'est pas un KPI dans un tableau de bord. C'est une conversation directe qui change la prochaine feature sur laquelle tu travailles. Écouter les utilisateurs, comprendre leurs vrais problèmes (pas ceux qu'on imagine), et résoudre ce qui compte vraiment, c'est la compétence la plus transférable que j'ai développée chez ncScale.
Avec le recul, je considère que les décisions techniques prises étaient les bonnes pour ce projet. Pas de regret majeur sur la stack ou l'architecture. Et si c'est rare de pouvoir dire ça après deux ans et demi, je pense que c'est justement parce que chaque choix a été fait en fonction du contexte réel du projet, pas d'une tendance ou d'un article Medium.
Ce que j'en retiens aujourd'hui
Deux ans et demi chez ncScale, c'est l'expérience qui a le plus façonné ma façon de travailler. Pas uniquement parce que j'ai touché à React, Symfony, Elasticsearch, Fastify, AWS. Mais parce que j'ai appris ce que signifie construire un produit de A à Z dans un environnement où chaque décision compte.
Si vous êtes développeur et que vous hésitez à rejoindre une startup early-stage, voici ce que je vous dirais : allez-y si vous voulez progresser vite. Pas juste techniquement, mais dans votre capacité à prendre du recul, à prioriser, à comprendre pourquoi on construit ce qu'on construit. C'est inconfortable par moments. C'est aussi là que la croissance se fait.
En startup, on ne se contente pas de coder. On construit.
Vous avez des questions sur cette expérience, sur les choix techniques, ou sur la réalité du quotidien en startup ? N'hésitez pas à me contacter, je suis toujours partant pour en discuter.
Voir NcScale en action
Envie de voir à quoi ressemble le résultat ? Cette vidéo vous donne un tour rapide de NcScale et de ce qu'on a construit.
![Comment j'ai développé une [[application de réservation en ligne]] sur-mesure pour une plateforme de téléconsultation](/_next/image?url=https%3A%2F%2Fsupabase.clementmenczynski.fr%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fimages%2Freservation-couple.webp&w=2048&q=75)