La première semaine dans une startup après des années en grande entreprise, tu cherches les templates. Le référentiel de documentation. Le processus de validation des specs. La personne responsable du pilotage.
Ils n'existent pas. Ou s'ils existent, personne ne sait vraiment où ils sont, ni si quelqu'un les a utilisés récemment.
C'est à la fois effrayant et incroyablement excitant. Bienvenue dans le BA en startup.
La vitesse, d'abord
En grande entreprise, une décision peut passer par plusieurs niveaux de validation, des comités et des revues. En startup, la même décision peut parfois se prendre en dix minutes lors d'un échange Slack ou autour de la machine à café. Ce qui semblait nécessiter trois semaines de processus peut se régler en une après-midi.
Au début, ça déstabilise. Tu cherches instinctivement les garde-fous, les validations et les personnes à aligner. Puis tu réalises que le fonctionnement est différent et que c'est souvent à toi de prendre l'initiative pour avancer. Il faut désapprendre le réflexe de l'attente et apprendre celui de l'action.
Cette vitesse est un carburant puissant. Elle réduit la distance entre l'analyse et l'impact : ce que tu définis le matin peut être en production quelques jours plus tard. Tu vois le résultat de ton travail rapidement et concrètement. Un luxe qui peut sembler rare quand on a connu des projets de dix-huit mois en grande organisation.
Mais cette même vitesse a un revers.
Les décisions rapides sont parfois prises avec peu de recul, peu de documentation et peu de considération pour les conséquences à moyen terme. Une solution qui fonctionne aujourd'hui peut créer de nouvelles contraintes demain. Un choix pratique dans l'urgence peut devenir difficile à remettre en question lorsque le produit grandit.
Le BA en startup apprend vite à trouver l'équilibre entre aller assez vite pour ne pas freiner l'élan et prendre suffisamment de recul pour ne pas créer des problèmes qu'on paiera plus tard.
L'objectif n'est pas de ralentir pour le plaisir de mieux documenter. C'est de savoir quand il faut avancer immédiatement et quand quelques questions supplémentaires peuvent éviter beaucoup de travail par la suite.
L'absence de process : liberté ou bombe à retardement ?
Pas de templates imposés, pas de comités de gouvernance, pas de methodology office qui surveille la conformité de tes livrables. En startup, tu fais comme tu penses que c'est juste.
C'est une liberté réelle et, pour quelqu'un qui aime construire, une opportunité rare.
Mais cette absence de process a une date de péremption.
Quand l'équipe est petite et que tout le monde se parle tous les jours, l'absence de formalisation ne pose pas nécessairement de problème majeur. Chacun sait plus ou moins ce qui se passe, les ajustements se font naturellement et les informations circulent facilement.
Le problème apparaît lorsque l'organisation grandit.
Une équipe de cinq personnes peut fonctionner grâce à des échanges informels. À vingt, certains oublis deviennent plus fréquents. À cinquante, selon l'organisation et la complexité du produit, le manque de structure peut sérieusement compliquer le travail.
Les décisions prises oralement il y a un an ne sont plus interprétées de la même façon par tout le monde. Les nouveaux arrivants n'ont aucune référence pour comprendre comment les choses fonctionnent. Des informations essentielles restent dans la tête de quelques personnes, qui deviennent malgré elles des points de passage obligés.
C'est souvent à ce moment-là qu'on réalise qu'on aurait dû documenter plus tôt.
Le même phénomène se joue côté technique, et il est encore plus insidieux.
Au début, le développeur fondateur connaît sa codebase par cœur. Il sait pourquoi tel morceau de code a été écrit de cette manière, pour quel client et avec quelles contraintes en tête. Une bonne partie de cette connaissance reste dans sa tête, et tant que l'équipe est petite, cela peut suffire.
Mais à mesure que le produit évolue, les spécificités métier se multiplient, les cas particuliers s'imbriquent et les choix techniques deviennent plus difficiles à comprendre sans leur contexte initial.
Une modification peut alors produire un effet inattendu sur une fonctionnalité existante. Onboarding un nouveau développeur devient plus compliqué. Débugger un comportement inexpliqué peut se transformer en enquête archéologique.
Le problème n'est pas simplement le nombre de lignes de code. C'est l'accumulation de décisions, de dépendances et de règles métier dont la logique n'est plus suffisamment documentée ou partagée.
C'est là que le BA peut jouer un rôle souvent sous-estimé : pas uniquement documenter les processus métier, mais contribuer à préserver le lien entre ce que le produit fait et pourquoi il le fait.
Pourquoi cette règle métier existe-t-elle ? Pourquoi ce cas particulier est-il traité différemment ? Quelle contrainte a conduit à cette décision ? Qu'est-ce qui risque de se passer si l'on modifie ce comportement ?
Le BA ne porte pas seul la responsabilité de la mémoire technique du produit. C'est un travail collectif avec les développeurs, les responsables produit et les autres personnes concernées. Mais il peut contribuer à rendre explicite une partie de cette connaissance qui, autrement, risque de disparaître.
Le BA en startup le plus précieux, c'est celui qui comprend ce paradoxe et sait doser : assez de structure pour que l'organisation tienne dans la durée, pas trop pour ne pas tuer la rapidité qui fait sa force.
Les casquettes qu'on ne t'avait pas dit
En startup, le BA ne fait pas que du BA. C'est une réalité qu'on découvre souvent en arrivant, plutôt qu'en lisant une fiche de poste.
Définir les process from scratch
Il n'y a pas de processus existant à analyser et à améliorer. Il faut parfois les créer.
Comment gérer les demandes entrantes ? Comment prioriser les développements ? Comment documenter les décisions produit ? Qui valide quoi ? Comment s'assurer que les mêmes informations sont disponibles pour tout le monde ?
Ces questions restent souvent dans un angle mort de l'organisation. Et c'est fréquemment le BA qui finit par s'en emparer, parce qu'il est bien placé pour repérer les frictions et les manques.
En startup, l'exécution est souvent ce qui fonctionne le mieux : on livre vite, on itère, on avance. Mais ce qui manque parfois, c'est la couche qui vient ensuite : la qualité, la standardisation et l'industrialisation.
On a construit quelque chose qui fonctionne pour dix clients. Est-ce que cela tiendra à cent ?
Les cas particuliers gérés à la main au début, comment les structurer pour qu'ils ne dépendent plus d'une seule personne ? Le onboarding client qui repose sur l'expertise d'un collaborateur, comment le documenter pour qu'un nouvel arrivant puisse le reproduire ? Le process de livraison qui fonctionne parce que tout le monde se connaît, comment le formaliser pour qu'il survive à la croissance de l'équipe ?
Ce sont des questions que le BA peut aider à poser avant qu'elles ne deviennent des problèmes urgents. Pas pour ralentir l'équipe, mais pour s'assurer que ce qui a été construit peut être répété, contrôlé et amélioré.
Passer de l'artisanat à l'industrialisation sans perdre la vitesse qui fait la force de la startup, c'est l'un des défis les plus intéressants du métier. Et ce travail n'est pas toujours attribué à quelqu'un de manière explicite.
C'est un exercice intellectuellement stimulant, mais qui demande une posture différente de l'analyse classique. Tu ne décris plus seulement un existant. Tu construis quelque chose qui n'existait pas encore.
Mettre les mains dans la technique
Celui-là, personne ne te le dit toujours dans les fiches de poste.
En startup, la frontière entre BA et rôle technique peut être poreuse. Tu peux te retrouver à explorer des APIs, à comprendre des structures de données, à tester des intégrations et à dialoguer avec des développeurs sur des sujets où tu dois avoir une opinion technique pour avancer.
Concrètement, ça veut dire savoir lire une réponse d'API et comprendre ce qu'elle contient, sans avoir besoin qu'un développeur te l'explique de bout en bout.
Ça veut dire comprendre pourquoi un flux d'intégration nécessite trois appels plutôt qu'un, et ce que cela implique en termes de performance ou de gestion des erreurs.
Ça veut aussi dire être capable de reproduire un bug dans un environnement de test, de lire un message d'erreur et d'en extraire l'information utile avant d'aller voir l'équipe technique.
Pas pour faire le travail du développeur, mais pour arriver avec un problème déjà diagnostiqué plutôt qu'une vague description d'un comportement inattendu.
Ce n'est pas du développement, tu ne codes pas nécessairement. Mais tu dois comprendre suffisamment le fonctionnement du produit pour ne pas être un simple messager entre le métier et la technique.
Le niveau de proximité technique attendu dépend de la startup, du produit et de la composition de l'équipe. Dans certains contextes, cette compétence devient particulièrement précieuse, notamment lorsque les intégrations sont nombreuses et que les équipes disposent de peu de temps pour approfondir chaque demande.
Le BA qui maîtrise cette dimension peut rapidement devenir un interlocuteur de référence pour les deux côtés. Quelqu'un qui comprend les contraintes métier et techniques, sans avoir besoin d'appartenir à un camp plutôt qu'à l'autre.
Ce que la startup t'apprend que la grande entreprise ne peut pas toujours t'apprendre de la même façon
La startup t'apprend à construire quelque chose à partir de rien et à assumer les conséquences de tes choix rapidement.
Il y a parfois moins de niveaux hiérarchiques pour valider tes décisions, moins de processus pour encadrer ton travail et moins de marge pour attendre que toutes les conditions soient réunies. Tu apprends à te faire confiance, à tester et à ajuster.
Tu découvres aussi une philosophie particulièrement adaptée à cet environnement : le test & learn.
Plutôt que de passer des semaines, parfois des mois, à analyser, cadrer, valider et revalider avant de toucher quoi que ce soit, l'équipe peut choisir de tester rapidement une hypothèse. Elle construit une version imparfaite, la met entre les mains d'utilisateurs réels, observe ce qui se passe et ajuste.
L'apprentissage vient du terrain, pas uniquement des slides.
Cela ne signifie pas qu'il faut supprimer l'analyse préalable. Il s'agit plutôt de concentrer l'effort sur les questions qui comptent vraiment, puis de confronter les hypothèses à la réalité le plus tôt possible.
En grande entreprise, j'ai pu constater que certains projets avançaient pendant des mois en cadrage, avec des dizaines de réunions et un budget validé, avant qu'une proof of concept ne permette de vérifier concrètement certaines hypothèses techniques ou fonctionnelles.
Lorsque cette confrontation avec la réalité arrive tard, corriger le tir peut devenir coûteux.
Dans une startup, les ressources sont souvent limitées et l'incertitude est forte. Tester tôt peut donc être un moyen efficace d'éviter d'investir trop longtemps dans une mauvaise direction.
On teste, on apprend, on échoue parfois, puis on recommence.
Tu apprends aussi à communiquer différemment.
En grande entreprise, tu peux passer des heures à préparer des présentations bien structurées et à organiser des réunions où les décisions n'avancent pas toujours autant que prévu.
En startup, tu dois parfois capter cinq minutes d'attention de quelqu'un qui court déjà vers autre chose, puis le convaincre en quelques phrases.
Pas forcément de slide de contexte ni de long récapitulatif des décisions précédentes. Tu arrives avec ton point, tu l'expliques, tu proposes une direction et tu repars avec une réponse, si les conditions le permettent.
La clarté de pensée n'est plus seulement une qualité appréciée. Elle devient une compétence particulièrement utile pour faire avancer les choses.
Enfin, tu apprends à regarder le produit dans sa globalité.
Parce que les équipes sont souvent plus petites et que les responsabilités se chevauchent davantage, tu peux être amené à explorer plusieurs dimensions du produit, des processus métier jusqu'aux intégrations techniques.
Cette proximité favorise une vision systémique. Tu comprends mieux comment les décisions prises à un endroit peuvent affecter le reste du produit et de l'organisation.
Ce n'est pas impossible en grande entreprise, mais le cloisonnement des équipes peut rendre cette vision plus difficile à construire.
La startup t'expose donc à une autre manière de travailler. Elle t'apprend à avancer dans l'incertitude, à prendre des initiatives et à adapter ton niveau de structure à la situation.
Et c'est probablement là que se trouve la principale leçon : il ne s'agit pas de choisir entre vitesse et rigueur, mais d'apprendre à trouver le bon équilibre entre les deux.
La suite
Ces deux articles, grande entreprise et startup, présentent deux contextes dans lesquels le BA peut évoluer. Aucun n'est parfait, et chacun développe des compétences différentes.
Dans le prochain article, on va parler de ce qui est en train de transformer les deux : l'IA, et la manière dont elle pourrait faire évoluer le métier de Business Analyst.
Tu es BA en startup ou tu envisages de faire le saut ? Abonne-toi à la newsletter pour recevoir régulièrement des analyses, des outils concrets et des retours d'expérience sur l'évolution du métier.