Julien Fournier - Tech Lead & Coordinateur d'agence
Découvrez notre calendrier de l'Avent spécial éco-conception
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
Title document
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
Cet article est destiné à aider les porteurs de projet ayant peu de connaissances relatives au développement d'application et abordant la question de la réalisation de leur MVP. Il a d'une part pour objectif de leur permettre de mieux appréhender les enjeux techniques auxquels ils vont faire face, mais également de les aiguiller sur la manière d'y répondre.
Après quelques années passées à développer, mon rôle chez Dernier Cri consiste aujourd'hui à identifier si nous sommes adaptés pour accompagner nos clients à créer ensemble une success story. Il est essentiel pour nous de bâtir des relations à long terme, et nous nous félicitons d'accompagner encore aujourd'hui des clients qui nous ont fait confiance depuis le premier jour de l'agence.
Lorsqu’on parle de “porteurs de projet”, il s’agit souvent de ces personnes qui ont d’excellentes idées, mais n’ont pas encore trouvé leur équipe technique. Pourtant, à force de recevoir des conseils de CTO déjà en poste avec des équipes de dizaines de développeurs et quelques millions d'euros de levés, ils finissent par se poser des questions qui peuvent sortir de leurs compétences, mais auxquelles il faudra pourtant répondre :
Se poser ces questions est important, voire indispensable au cours de la vie d'une startup. Elles sont souvent le reflet d'un succès qui peut arriver plus vite que prévu. Aussi surprenant que cela puisse paraître pour des béotiens, la réponse n'est pas immuable, bien au contraire. Ce qui est vrai et efficace à un moment s'avérera plus tard faux ou inadapté. C'est d'ailleurs pour ça que les équipes techniques des startups tendent à grossir, et non à se réduire une fois le succès rencontré.
Pour chacune de ces questions, dans 99% des cas la réponse est la même : la plus pragmatique et la moins coûteuse. Je vais tenter de vulgariser les enjeux, de préciser les possibilités et in fine d'y répondre.
Cette question, souvent un peu floue pour les non-initiés, porte sur la manière de structurer son projet. En effet, lorsqu'on développe une application, il n'est pas rare qu'on puisse identifier différentes briques logicielles, souvent liées à des périmètres fonctionnels distincts. On est alors en droit de se demander s'il ne faut pas immédiatement isoler une partie de l'intelligence pour la rendre autonome.
La réponse à cette question offre 3 macro-possibilités :
Un monolithe consiste en une seule et même base de code regroupant l'intégralité du projet.
L'approche dite servicielle consiste à siloter les grandes entités fonctionnelles pour qu'elles puissent interagir avec d'autres services existants, et ce, de manière autonome.
L'approche "micro-services" a été popularisée par des ingénieurs d'Amazon, qui ont poussé à l'extrême l'approche services pour que chaque composante du parc applicatif puisse être utilisée de manière indépendante, disposant ainsi de ses propres APIs. Le graal de tout architecte applicatif.
Nous avons récemment accompagné une startup qui se séparait de son CTO, et qui avait opté pour une architecture logicielle en micro-services pour un MVP. Au programme, pas moins de 50 projets, 4 jours d'onboarding pour pouvoir effectuer nos premières modifications. Une véritable hérésie que le client va payer le prix fort pendant encore un moment.
Il faut garder en tête que les budgets et ressources dont Amazon dispose sont quasiment illimités. Il est donc réaliste de croire que dans un tel contexte, Amazon Web Services en l'occurrence, le micro-service offre un véritable intérêt, puisque chacun de ces écosystèmes de micro-service sont une offre à part entière. Néanmoins, je suis beaucoup plus septique sur le fait de croire que la première version d'Amazon disposait déjà d'une architecture micro-services. Je suis même prêt à parier le contraire.
Mais au-delà du budget, pourquoi ne pas passer tout de suite sur du micro-services ?
Tout simplement parce qu'à ce stade, vous ne pouvez pas siloter les différentes entités fonctionnelles de manière pertinente.
L'isolation d'une brique logicielle se fait de manière rétrospective. En particulier lorsqu'elle est identifiée comme critique, qu'elle ne répond plus correctement à vos attentes, ou encore lorsqu'il devient nécessaire de la barder de tests. En d'autres termes, l'isolation de cette brique se fait généralement dans un contexte de refonte chirurgicale et donc maîtrisée.
Choisir le micro-services revient à accumuler immédiatement de la dette technique et à alourdir considérablement la manière dont vos services communiqueront et cohabiteront : c'est la double peine. Sans oublier qu'un micro-service à un coût en tests extrêmement lourd, au-delà la surcharge de travail liée à sa mise en œuvre.
Ainsi, démarrer avec une architecture monolithique, puis la faire muter en services et enfin en micro-services, doit être perçu comme une maturation progressive de son application.
Pour toutes ces raisons, vous devriez systématiquement privilégier une approche monolithique pour lancer votre projet.
C'est de loin la question la plus commune avec celle concernant les langages. En effet, il existe une multitude de technologies permettant le stockage de ses données.
Il existe deux grandes familles de bases de données. Celles dites relationnelles et, par opposition, les… non-relationnelles.
Une base de données relationnelles est interrogeable via du SQL. C'est avec ce langage que les développeurs interagiront avec la base de données.
Les bases de données non-relationnelles se découpent en plusieurs grandes familles. Elles peuvent être orientées document, à clés et valeurs, ou encore organisées en graphes. Elles ont été essentiellement inventées pour répondre à des problématiques plus ou moins récentes, notamment sur des sujets de performance de lecture, d'enregistrement, ou encore pour stocker des informations ayant un format particulier, par exemple des images. Pour autant, il n'existe pas de solution parfaite, et chacune de ces solutions offrira son lot d'avantages et d'inconvénients selon son contexte de mise-en-œuvre.
À l'instar des hypothèses faites pour l'architecture micro-services, il est tentant de vouloir immédiatement intégrer dans son écosystème une variété de bases de données. On répond ainsi à chacune des probables problématiques identifiées en amont du développement.
Pourtant, l'essence du NoSQL est historiquement de répondre à des problématiques liées à la gestion de volumes de données colossaux, le fameux big data. On parle de milliards d'enregistrements. Or on est très rarement confronté à un gros volume de données dans le cadre d'un MVP.
Il m'a été remonté, à juste titre, que certains systèmes de base de données, tels que MongoDB, sont particulièrement flexibles pour faire évoluer des modèles. Cette démarche est effectivement vertueuse dans le cadre d'une épreuve de concepts, mais son intérêt sera plus rapidement discutable à moyen terme. La lourdeur dans la manière de réaliser des requêtes complexes finira forcément par porter préjudice à l'application dès lors qu'elle sera fortement exploitée.
Il existe quelques signaux annonciateurs quant à l'intérêt d'intégrer progressivement de nouvelles bases de données dans votre stack.
Par exemple, lorsqu'une forte dégradation des performances d'une fonctionnalité est constatée et nuit à l'expérience utilisateurs. Après que tout ait été tenté pour optimiser les performances, mettre en place des index, augmenter raisonnablement la mémoire, réécrire les requêtes les plus lentes. Attention cependant, ce genre de fonctionnalités est très certainement cœur au sein de votre application. S'il s'agit de l'étape de connexion, il est probable que des optimisations soient encore à prévoir.
Un autre cas intéressant concerne le besoin de procéder à une analyse poussée de certaines données clés. Dans ce cas, il pourra être nécessaire de déporter ces données sur une architecture différente dès que la volumétrie sera significative. À nouveau, on parle de milliards de records au minimum.
Pour les mêmes raisons que pour la question précédente, le choix d'une base de données monolithique, robuste et standard vous couvre contre 99% des risques de mauvais choix. Le fait de ne pas baser ses choix sur des hypothèses supprime le risque que ces hypothèses soient fausses et remette en cause le château de cartes que vous êtes à ce stade en train de bâtir.
Nous nous orientons généralement vers PostgreSQL qui présente de nombreux avantages. En particulier une excellente couverture de la norme SQL (>95%), et d'excellentes performances pour une très grande variété de données.
Nous vivons dans une époque formidable, où la plupart des problématiques liées à l'hébergement, et en particulier sur la rationalisation des contraintes qui y sont liées, ont été très largement taclées.
Ainsi, il existe aujourd'hui des prestataires qui, non contents de proposer des serveurs, fournissent également la configuration des machines. Il n'y a plus qu'à y déposer son application et tout fonctionne. On parle de PaaS (plateforme à la demande) par opposition aux offres dites IaaS (infrastructure à la demande)
Leurs équipes d'ingénieurs sont dédiées à plein temps à améliorer les performances et la sécurité, le tout étant répliqué à l'échelle des différents data centers. Vous bénéficiez ainsi d'une équipe dédiée 24/7.
La contrepartie est évidente : là où des hébergements traditionnels coûtent 2 à 5€ par mois et par instance, on arrive assez vite à des montants de l'ordre de 50€ par mois pour héberger son application. Forcément, on est en droit de se poser la question de pourquoi payer dix fois plus cher un service qu'on est capable de faire soi-même.
La réponse est pourtant simple : pour gagner du temps et économiser de l'argent.
Afin d'être plus explicite sur les coûts cachés à la mise en place de votre propre infrastructure, celle-ci se déroule en deux étapes.
La première est appelée le setup. Elle consiste à louer les serveurs, à les configurer, à y installer l'ensemble des briques logicielles nécessaires à votre application (serveurs de bases de données, serveurs d'application ...), à rédiger des scripts de déploiement, à mettre en place des règles de sécurité, et j'en passe. Il n'y a pas de durée précise pour un setup. Il dure généralement entre 2 jours et 2 semaines de travail, selon l'expérience et la volonté de bien faire de votre CTO.
Vient ensuite la phase d'exploitation. C'est-à-dire la période où votre infrastructure est opérationnelle et où il est nécessaire de réaliser les opérations de maintenance, de déploiement, de faire évoluer les scripts, de modifier les performances d'un serveur un peu lent. L'exploitation prend rarement moins d'une journée par mois surtout en phase de croissance. Elle peut s'accompagner de downtimes très pénibles et délétères pour le produit pendant les pics de fréquentation. Les fameux passages sur Capital le dimanche à 22h.
En considérant que, chargé, un CTO peut rapidement coûter 8000€/mois sur Paris en 2019, soit 400€ par jours, cela représente un coût de setup d'environ 2000€ et un coût de maintenance de 400 à 800€ par mois hors coûts d'infrastructure.
Par opposition, un setup pour du PaaS prend rarement plus de 2h à 1/2 journée, l'exploitation, environ 10 minutes en cas de besoin de monter en puissance sur l'un d'un serveur. Bref, il existe un facteur de 10 à 100 entre le coût perçu et le coût réel.
Mais alors quand faire la bascule ?
L'exploitation d'une architecture est normalement réalisée par un profil de type Ops. Tant que le coût mensuel de votre hébergement ne dépasse pas le prix chargé de cet ops, à savoir au minimum 5000€ par mois, ne réfléchissez même pas à migrer votre architecture.
Ainsi, le choix d'une architecture de type PaaS, tel que Clever Cloud, Scalingo ou encore Heroku, est de loin la meilleure opportunité pour vous de vous assurer quelques années de sérénité.
Clever Cloud et Scalingo sont deux solutions françaises, sécurisées et robustes, qui garantissent la localisation de vos données. Faites vous votre propre avis, les deux sont excellentes !
Heroku est plus avancé en termes de fonctionnalités, avec une intrication forte dans l'écosystème Salesforce, via le Heroku connect notamment. Néanmoins, gardez en tête que même si vous choisissez un serveur basé en Europe, il est probable qu'une sauvegarde de ce dernier (et de vos données) se retrouve régulièrement outre atlantique.
Ne vous inquiétez pas cependant pour vos dizaines de milliers d'euros de crédits qu'Amazon, Google ou Microsoft vous ont offert, vous les utiliserez plus tard.
Cette question justifie à elle seule un post que j'ai déjà commencé à rédiger. Pour ne pas aborder le sujet en surface, j'aborderai donc cette question dans un post dédié.
La création d'une startup requiert de savoir discerner les décisions importantes des décisions prosaïques qu'on tente de rendre importantes. Les questions techniques auxquelles on cherche à répondre sont pour l'extrême majorité de ce second type. De faux enjeux avec de faux débats qui n'auront comme conséquence que de perdre le focus, voire pire, s'ils venaient à en faire un véritable sujet et ainsi prendre de mauvaises décisions.
Gardez en tête que votre objectif est d'arriver à démontrer à vos utilisateurs que votre produit leur apporte de la valeur, AKA trouver votre market fit. Rien d'autre.
Pour le CTO en revanche, tous ces enjeux techniques sont essentiels, voire importants. Il est donc essentiel de très vite arriver à un consensus sur le fait que tout le superflu devra être traité dans un second temps.
C'est d'ailleurs pour réduire ces risques de départ que de plus en plus de startups font le choix de nous confier la première version de leur produit. L'arrivée du CTO n'en est que plus confortable, car le risque de défaillance technique a pu être évincé dès le départ.
Vous souhaitez monter votre startup et vous vous posez d'autres questions ?
J'y répondrai avec plaisir, voire mettrai cet article à jour si des questions sont récurrentes.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
