Construire la techno d’une startup : quelques pistes pour débuter

Hier soir, vous avez trouvé une idée de produit géniale et vous vous êtes décidé à vous lancer en tant que CTO d’une nouvelle startup : il y a une équipe, une idée de produit, une vision, et toute la techno est à construire. C’est probablement le moment le plus excitant. Voici quelques pistes si vous ne savez pas trop par où commencer.

Penser les méthodes avant de commencer le dev

Avant de se lancer tête baissée, il est important de se fixer quelques règles simples pour que tout se passe bien par la suite. Il faut trouver un équilibre, en partant sur de bonnes bases structurantes, tout en limitant le formalisme et le nombre d’outils (on n’a pas encore commencé à écrire une ligne de code!).

A mon sens, le minimum vital est constitué par :

  • un système de gestion de version de code : c’est l’outil indispensable pour écrire du code sans le perdre et en gérant plusieurs versions et plusieurs collaborateurs. GIT est aujourd’hui le système le plus répandu, mais d’autres existent (SVN...)
  • un système de documentation minimal : un wiki par ex.
  • un outil de suivi de projet : si vous n’êtes pas familier des méthodes agiles, partez sur des choses simples. Un système de gestion de tâches avec des tickets peut suffire (redmine est open-source, facile à installer). Trello est aussi un bon début, simple à prendre en main. Si vous êtes un peu plus sûr de vous, Jira est bien
  • une répartition des tâches claire et une politique d’accès qui va avec : qui spécifie ? qui développe ? qui teste ? qui déploie ? (la question est facilitée si vous êtes seul !)

Un peu d’archi: penser modularité, faire des choix

Une fois que le produit est plus ou moins bien défini, vous pouvez commencer à concevoir une première architecture pour votre techno. Votre produit peut être très disruptif d’un point de vue business, tout en ayant besoin d’une architecture très simple (site web avec une DB derrière). Vous trouverez plein de doc et de conseils sur ces architectures classiques. L’enjeu principal est alors le passage à l’échelle.

Mais votre produit est peut-être beaucoup plus exotique, avec des contraintes très particulières (répondre en moins de 100µs ? optimisation de la conso éléctrique ?), des protocoles tordus peu connus, etc. Dans ce cas, vous êtes un peu seul et c’est à vous d’inventer des solutions en piochant ici ou là des idées.

Dans les deux cas, une question récurrente est de savoir si vous devez partir sur une archi pour faire fonctionner un prototype, ou si vous devez déjà penser votre architecture pour le produit final. Il n’y a pas de réponse simple, car vous allez rencontrer rapidement deux obstacles: i) il est très dur de changer la techno une fois que vous êtes en production (et dès que votre proto fonctionnera, vous voudrez le mettre en prod) et ii) il est indispensable de changer de techno parfois.

Donc le seul bon conseil est de rendre tout changement le plus facile possible. Pour cela, votre architecture doit être modulaire, en laissant la possibilité de changer chaque brique indépendamment. L’approche micro-services est la forme la plus poussée de cette idée. C’est une quasi-évidence aujourd’hui, mais on rencontre encore des partisans de l’approche monolithique, qui estiment que les performances sont plus faciles à atteindre avec un groc bloc infâme bien dense et impossible à maintenir.

Les premières lignes de code, premier build, hébergement et monitoring

Avec votre IDE favori, vous avez déjà écrit quelques lignes qui compilent. Good.

Oh et vous avez même écrit des tests unitaires (avant d’écrire le code ? encore mieux! TDD rulez), qui passent. Very good.

Il ne vous reste plus qu’à compiler (selon votre techno), et trouver un mode d’hébergement de vos services: serveurs dédiés ? Cloud ? Ca dépend de vos besoins et de votre budget. Il faut bien séparer environnement de dev (local) et environnement de prod (hébergé) pour assurer un minimum de stabilité. Deployez vos services manuellement ou automatiquement, selon ce que vous maîtrisez.

En général, les services plantent : il est indispensable d’avoir un monitoring fiable très rapidement dans votre stack, et Nagios est votre ami. Plutôt simple à mettre en place, Nagios vous fera mieux dormir la nuit (ou te reveillera c’est selon), en détectant tous les plantage de tes services. A mon sens, il faut développer les tests Nagios avant de développer les services (encore plus que les tests unitaires et d’integration).

Pour un prochain post

Les méthodes de dev, l’intégration continue et le déployement automatisé. Si vous pouvez/savez les mettre en place dès le début, très bien ! Mais si vous n’avez pas d’expérience sur ces sujets, gardez cela pour la semaine prochaine.