Infrastructure et organisation des start-up Data

Après une école d’ingénieur à Télécom Paris, je suis parti dans la Silicon Valley pour un stage, puis un premier emploi, puis un autre… Au cours de ces huit ans, j’ai parcouru un spectre assez large de sociétés et de technologies, ce qui m’a permis de voir des structures et des organisations techniques assez différentes.

Mon premier stage était plutôt orienté recherche et construction de prototypes (interface homme-machine, moitié hardware, moitié software), puis chez Oracle je suis passé sur de l’Enterprise Software en Java, des systèmes distribués puissants qui allaient être utilisés par les opérateurs telecom dans leur back-end transactionnel (appels, etc.).

Je suis ensuite entré chez Yelp  : on développait un site web qui reçoit des centaines de millions de visiteurs par mois, avec un énorme back-end et des centaines de serveurs qui tournent. Je me suis orienté côté infrastructure : comment créer et gérer une architecture multi-services, comme déployer tous ces services en utilisant diverses techniques (Docker, mise en place d’une culture DevOps etc.) et sécuriser tout cela. Je me suis aussi intéressé aux pipelines de données, à la construction de systèmes d’analyse des visites sur le site, etc. Donc des systèmes comme MapReduce pour analyser des téraoctets de données d’un coup, du distributed computing et divers outils d’analyse.

Par la suite, je suis passé en start-up où l’on ne perd pas le côté ingénieur mais où on gagne en plus le côté Produit assez rapidement car on est proche des clients et des besoins auxquels le logiciel essaye de répondre. J’ai donc touché à beaucoup plus de choses comparativement à mes expériences précédentes, même si c’était un peu moins en profondeur parce qu’il fallait arriver plus rapidement à mettre en place un produit, toucher au back-end, au front-end, un peu à tout ! Niveau technologies, c’était du cloud car quasiment aucune start-up n’a ses propres serveurs, tout est dématérialisé. C’était surtout sur des frameworks web, Python, Scala et diverses bases de données, relationnelles ou non…

Petit à petit mon rôle s’est transformé en un rôle de Tech Lead, puis de manager d’équipe. Je gérais une équipe de huit personnes qui s’occupait de tout le côté Data de la start-up : gestion des data pipelines, collecte, stockage, analyse des données, développement de systèmes de Machine Learning et création d’une plateforme analytique qui permettait aux clients d’accéder à toutes leurs données.

Ce qu’il est fondamental de comprendre quand on passe du côté start-up, c’est que la technique prend une place secondaire par rapport au business et au produit. Si on monte ou rejoint une start-up juste pour construire des briques techniques, il y a très peu de chance que ça marche. La plupart des start-up ne se plantent pas parce qu’elles n’ont pas le bon niveau technique, elles se plantent parce que personne ne veut payer pour leur produit.

J’en ai fait l’expérience dans la première start-up que j’ai rejointe : c’était l’équipe technique la plus pointue que j’ai connue, toute petite mais vraiment très technique, des gens brillants, on a développé des choses impressionnantes techniquement, on a construit une plateforme de communication multi channels, qui marchait sur toutes les plateformes mobiles et web possibles, que ce soit par vidéo, par message, etc. On a aussi construit toute une plateforme de Machine Learning qui permettait de faire de l’analyse de textes, et de comprendre en temps réel les questions posées par les utilisateurs, c’était très intéressant… Mais au final, la start-up n’a pas bien fonctionné parce que le product market fit n’était pas là, personne ne voulait payer pour le produit.

J’étais en premier lieu attiré par l’idée de rejoindre une start-up, c’était la première fois que j’en rejoignais une. J’avais rencontré le CTO qui avait fait Telecom Paris quinze ans avant moi, qui s’était aussi retrouvé dans la Silicon Valley et qui m’avait convaincu. J’avais identifié des choses un peu surprenantes dans les choix de features qu’ils avaient développées, qui me paraissaient coûteuses en développement par rapport à la valeur qu’elles ajoutaient pour les utilisateurs. Mais comme je n’y connaissais pas grand-chose en produit, cela ne me paraissait pas être un problème. Je pense (j’espère en tout cas) qu’aujourd’hui, si j’avais à refaire la même analyse, je détecterais qu’il y avait un problème à ce niveau-là. Mais c’était malgré tout une super expérience, non seulement parce que j’ai eu la chance de continuer de travailler avec les collègues brillants que j’y ai rencontrés, mais aussi parce qu’elle m’a montré clairement qu’on peut avoir une super équipe et développer un super produit mais que cela ne sert pas à grand-chose si ce n’est pas un produit que les gens veulent et pour lequel ils sont prêts à payer.

Cela m’a aussi appris que ça ne sert à rien d’investir beaucoup dans la technique avant d’avoir « vérifié » le produit. C’est à dire valider que ce que l’on construit répond à un réel besoin des utilisateurs. On en revient à la question que vous avez posée : pour moi le prérequis technique est surtout de savoir être le plus minimaliste possible dans la solution technique qu’on veut construire, et d’essayer en permanence de trouver des raccourcis pour vérifier le business, vérifier son produit, tout en investissant le moins possible dans la technique.

Cela peut paraître déprimant pour un ingénieur de dire ça, mais je suis partisan de la low tech en quelque sorte. Par exemple, dans cette start-up, nous avons développé une plateforme de communication très complexe alors que nous aurions pu tester une grande partie de nos hypothèses produit en construisant une première solution par SMS très simple. En voyant que les gens ne voulaient pas payer pour cela, nous nous serions peut-être rendus compte qu’il n’était pas nécessaire d’investir plus pour développer l’aspect vidéo par exemple. Le temps gagné nous aurait permis de tester d’autres possibilités de produits avant d’être à court de financements !

Donc pour moi le choix technique à faire au départ, c’est surtout de trouver comment réduire au maximum ce qu’on va devoir construire pour tester ses hypothèses produit, et d’utiliser le plus possible des services existants. Aujourd’hui c’est fantastique, il existe une offre de produits incroyable lorsque l’on construit un nouveau business, qui permettent d’être très efficace sans avoir à écrire quasiment aucun code. Il faut donc arriver à repérer les bons produits, que ce soit techniques pour simplifier et accélérer les développements nécessaires, ou pour l’équipe marketing/customer pour communiquer avec ses clients efficacement.

Il faut exploiter tout cela, maximiser les quick wins opérationnels avec des outils à disposition et arriver à repousser les efforts de développement plus lourds le plus longtemps possible. Je dirais qu’il y a deux facteurs qui jouent contre le développement technique : d’une part les ingénieurs sont très chers par rapport à l’achat d’un outil existant, et d’autre part il y a les coûts de maintenance du code. Quand on écrit un programme, on ne résout jamais le problème pour toujours et « on n’en parlera plus ». En réalité, on change souvent de direction, surtout dans les start-up : tout code qu’on écrit devra un jour être modifié voire supprimé, et donc tout investissement qu’on fait dans le code implique des coûts de maintenance futurs qui peuvent devenir élevés. C’est contre intuitif, mais modifier un logiciel existant peut parfois coûter plus cher que de l’écrire depuis zéro, en particulier parce qu’il faut supporter et convertir toutes les données et utilisateurs déjà existant dans le programme. Rester lean et aller le plus loin possible dans la découverte du produit à construire tout en ayant le minimum de code à maintenir permet donc à la fois de réduire ses coûts mais aussi d’arriver plus vite à un produit qui répond aux attentes des consommateurs.

Les principes sont les mêmes pour les start-up Data, ça a beaucoup évolué dans les 5-6 dernières années et on a aujourd’hui tout un tas d’outils qui permettent de ne pas avoir à développer sa propre infrastructure – par exemple avec des outils qui permettent de créer des clusters Spark clé en main, on peut directement faire toutes les analyses sans avoir à construire la stack technique soi-même. Cela dit, pour la Data, il y a quand même un aspect important : ce que la start-up va vendre à ses investisseurs, c’est souvent une « défendabilité » (moat en jargon Silicon Valley) basée sur la quantité de données accumulées. Cela veut dire qu’il faut bien réfléchir, dès le début, à quelles données on va vouloir récupérer, comment on va les traiter, et comment on va organiser le tout pour que ce soit exploitable au final.

Il faut donc arriver à combiner le côté minimaliste sur les outils avec une réflexion assez poussée sur le stockage des données, leur organisation (qui devient très compliquée quand on commence à collecter plein de choses), l’organisation du data pipeline, quelles données vont pouvoir être modifiées plus tard et quelles données on va pouvoir stocker telles quelles, mais aussi penser l’évolution du système, réfléchir à comment un changement dans notre code va affecter les données existantes, est-ce qu’on va devoir à chaque fois reformater toutes les données existantes pour les adapter au nouveau code, comment on va réagir quand inévitablement un bug corrompt une partie des données stockées, etc.

Au final, comme pour toute start-up, le code qu’on choisit de développer nous-même doit être centré sur le cœur du business, sur ce qui fait le côté unique du produit qu’on développe. Donc pour une start-up Data, c’est très probablement sur le code qui va toucher les données qu’il va falloir faire le plus d’investissements en interne. Attention toutefois à ne pas tomber dans le biais que j’ai parfois pu observer qui consiste à embaucher des experts Data Scientist ou Machine Learning trop tôt : ces profils spécialisés peineront à se rendre utiles si une stratégie et infrastructure de collection et gestion des données n’est pas déjà en place – à moins qu’ils ne soient bien sûr suffisamment généralistes pour pouvoir aider à cette mise en place !

L’avantage d’une start-up est que, comme l’équipe est petite et tout le monde est assez proche, la communication est très rapide, les ingénieurs sont proches des clients, et on saute beaucoup d’étapes de communication par rapport aux grandes entreprises. Il est donc important de mettre en place des principes organisationnels et des process qui permettent de tirer avantage de cette caractéristique. Mais si on s’y prend mal, en cas de croissance rapide, cela peut aussi rapidement devenir chaotique, avec personne qui ne sait trop à qui parler, trop de données en même temps, etc.

Une bonne pratique organisationnelle est avant tout une organisation efficace du transfert de l’information. A chacun de trouver la façon dont il aime travailler, mais avoir une certaine cadence en général assez courte, c’est-à-dire de l’ordre de la semaine (on peut appeler cela un sprint, mais il y a tout un tas de méthodologies existantes), où tout le monde se retrouve ensemble et regarde comment la start-up avance, et ce sous tous les points de vue d’ailleurs, est une bonne chose. Il faut que l’équipe technique explique au reste de la start-up ce qui est train d’être mis en place pour que l’équipe support (entre autres) puisse communiquer au client, mais il est aussi important que les profils techniques soient au courant de ce que l’équipe commerciale est en train de vendre pour qu’ils puissent anticiper sur ce qui va arriver. Donc avoir des points très réguliers qui permettent de bien partager l’information au sein de la start-up est primordial.

Ce fonctionnement ouvert sous-entend que beaucoup de gens peuvent venir parler directement à l’équipe technique, ce qui fluidifie le fonctionnement mais peut aussi créer des tensions et des difficultés à prendre des décisions. Par exemple, votre commercial peut vendre une nouvelle feature alors que dans le même temps votre customer service vous explique qu’il y a de gros problèmes sur une autre feature existante avec plusieurs de vos clients : comment arbitrer pour que l’équipe technique ne fasse pas la girouette entre différents projets ? Le système de décision nécessaire va souvent s’organiser autour d’un Product Manager ou Chief Product Officer, quelqu’un qui va être le pilier, qui va tenir le gouvernail sur les orientations et les priorités pour l’équipe technique.

Le Produit, que ce soit une équipe ou une personne seule au début (auquel cas il s’agit souvent du CEO ou du CTO), va devoir être l’organisateur de la communication et de la prise de décision, et arbitrer autant que possible des décisions entre les différentes personnes qui voudraient voir de nouvelles features ou des améliorations dans le produit.

Il reste très important d’impliquer les ingénieurs dans le côté business de la start-up. Ce que j’ai vu qui fonctionnait bien, c’est de pousser les ingénieurs à participer aux appels avec les clients. Par exemple, un ingénieur une fois par semaine ou une fois par mois va avec le commercial participer à une discussion avec un client. Cela permet de développer beaucoup plus d’empathie avec les clients, de comprendre ce qui est important pour eux, d’améliorer la motivation et la compréhension de ce pour quoi on fait les choses.