Choisir ses technologies

Lors que vous démarrez votre activité ou que vous passez de la preuve de concept (POC) à l'industrialisation, se pose invariablement la question des technologies à choisir pour faire de votre projet une réussite. Dans certains rares cas, une technologie s'impose par sa quasi-hégémonie sur un marché mais, dans la majorité des cas, l'éventail des choix est assez large. Comment choisir la technologie qui répondra le mieux à vos besoins actuels et à venir ? À noter que cette réflexion, bien qu'importante initialement, se pose aussi régulièrement dans le cycle de vie d'un produit : refonte complète, ajout de fonctionnalités structurantes, mises à jour régulières, ... Les critères de choix sont néanmoins proches pour toutes ces étapes.

Les choix à réaliser

Choisir une technologie ne se résume pas à choisir un langage ou un framework. En effet, toute application est composée de nombreuses parties qui dépassent largement ces 2 éléments :

  • la base de données : dans l'immense majorité des applications, des données vont être stockées. En fonction du type de données à stocker (volumétrie, consistence, temporalité de la collecte, manière de relire cette donnée, ...), la base de données devra être adaptés. Il n'existe en effet, aucune solution qui réponde à tous les besoins simultanément. Il est même tout à fait possible que vous ayez besoin, un jour ou l'autre, de plusieurs bases de données pour remplir tous vos cas d'usage.
  • l'hébergement : pour que le code écrit par vos équipes d'engineering ait de la valeur, il faut qu'il s'exécute quelque part. Même si certains projets ne nécessitent que du code qui s'exécute sur le device de l'utilisateur, la grande majorité des applications aura besoin d'un serveur pour déployer son code et le faire exécuter. L'écosystème de l'hébergement a énormément évolué depuis l'arrivée d'AWS en 2006 : Cloud Computing, Serverless, Containerisation, ... Les paradigmes d'il y a 10 ou 20 ans ne sont plus du tout les mêmes que ceux d'aujourd'hui.
  • le déploiement : même si le lien avec l'hébergement est ténu, la manière d'héberger et de déployer son code est une réflexion à avoir à part entière. En effet, même si GitHub et GitLab sont aujourd'hui plébiscités dans de nombreux projets, le sujet de l'hébergement du code est crucial : si votre principal actif est un actif technologique, perdre le code source qui le compose aurait un impact tragique sur votre activité et votre valorisation. De la même manière, être capable de déployer rapidement et à interval régulier ce code est une brique fondamentale de votre capacité à créer un actif technologique de premier plan. Les solutions de "build" et de déploiement du code sont nombreuses et le choix doit être guidé par les mêmes critères que pour un langage ou un framework

Enfin, votre stack technologique ne sera probablement pas constituée que d'un seul langage et un seul framework. L'immense majorité des applications a besoin d'au moins un langage et un framework Backend et d'au moins un langage et un framework Frontend. Et encore, si vous ciblez aussi le marché du mobile, vous aurez probablement un choix à faire pour choisir votre ou vos frameworks Mobile !

Analyse de votre contexte actuel

La première étape avant de réaliser un choix est d'étudier votre contexte. En effet, même si vous en êtes encore à l'état de réflexion sur votre projet et qu'aucun développement n'a commencé, des premiers éléments de contexte existent déjà :

  • avez-vous quelques connaissances en développement qui pourraient servir ? Vous n'avez peut-être pas fait d'école dans le domaine du développement informatique ou vous n'avez peut-être pas travaillé dans ce domaine pendant votre carrière, mais vous pouvez avoir une appétence pour ce sujet et avoir fait des petits projets à côté. Si c'est le cas, ces projets peuvent vous orienter pour vos futurs choix.
  • avez-vous envie de vous impliquer dans le développement de votre produit ou préférez-vous laisser ce travail à d'autres personnes ? Si vous souhaitez vous impliquer dans une phase de POC, de nombreux outils de "No-Code" peuvent vous aider à monter une première expérience de votre projet assez rapidement. Attention toutefois : dans la majorité des cas, la qualité et l'évolutivité de ce type de solution est assez limitée. Mais pour réaliser une preuve de concept, cela peut être largement suffisant.
  • où vivez-vous ? La question peut paraitre éloignée de ce type de choix mais elle ne l'est pas tellement : historiquement, certains bassins d'emplois sont plus marqués par certaines familles de technologies. Si vous avez besoin de recruter dans le futur et que vous planifiez de le faire localement, les choix que vous ferez aujourd'hui peuvent conditionner votre capacité à recruter demain. Si vous prévoyez de ne recruter que sur des postes en Full Remote, la question est moins importante et c'est plutôt sur l'outillage pour faire communiquer les équipes que vous aurez des choix plus structurants à réaliser.
  • quelles sont vos capacités financières ? Certaines technologies sont moins démocratisées que d'autres. Le recrutement sera d'autant plus complexes et les profils disponibles potentiellement plus chers que sur d'autres technologies. Idéalement, un développeur peut travailler sur plusieurs langages et plusieurs frameworks au cours de sa carrière mais, dans la réalité, avec la complexité grandissante du milieu du développement, les développeurs se spécialisent tous sur quelques langages, frameworks, bases de données, méthodes de déploiement, ... Choisir une technologie exotique peut donc avoir un impact important sur voter masse salariale.
  • si vous avez déjà une ou plusieurs personnes dans votre équipe de développement, quels sont les technologies qu'ils maitrisent le mieux et avec lesquelles ils se sentent le plus à l'aise ? Choisir une technologie déjà maitrisée par votre équipe en place va vous permettre de créer de la valeur plus rapidement que si vous aviez à former toute votre équipe sur quelque chose de nouveau. De plus, l'expérience montre que c'est, souvent, sur le troisième projet utilisant une nouvelle technologie (ou méthodologie, concept, ...) que l'équipe réalisera son meilleur travail. Si vous faites le choix d'une technologie nouvelle pour votre équipe, il serait plus prudent de commencer par leur donner un premier projet qui ne soit pas au centre de votre proposition de valeur et de votre actif technologique.
  • à quoi ressemble votre roadmap actuelle ? Si vous en avez déjà établie une, vos objectifs de création de valeur à court terme doivent déjà être clairs et vont avoir un impact fort sur votre choix. Ainsi, si vous avez des échéances importantes qui arrivent à très court terme, choisir une nouvelle technologie que ne maitrise pas votre équipe présente un risque considérable. À l'inverse, si vous avez une échéance à plus long terme, vous pouvez certainement vous permettre un choix plus guidé par une logique de long terme mais il faudra alors parfaitement mesurer les avancées à interval régulier pour ne pas manquer cette échéance.

Vision moyen terme

Après avoir fait une analyse de votre contexte actuel, vous devez vous poser des questions sur la vision que vous avez pour votre entreprise à moyen terme. Il n'est pas nécessaire et même contre-productif d'avoir une vision à trop long terme qui pourraient vous faire faire des choix pour un avenir potentiel au détriment de votre contexte actuel. Néanmoins, avoir une vision de 2 à 3 ans à venir peut vous aider à faire des choix plus éclairés. Quelques élements à prendre en compte :
  • vos besoins en recrutement : si vous prévoyez une activité qui va nécessiter de nombreux recrutements, choisir une technologie exotique peut vous mettre en forte difficulté au moment de faire grandir votre équipe engineering. Certaines technologies récentes arrivent souvent avec des promesses de faire gagner du temps à votre équipe mais, souvent, au prix d'une courbe d'apprentissage lente. Si cette technologie est peu répandue sur le marché (car récente par exemple), vous allez devoir embaucher des développeurs qui vont devoir l'apprendre en arrivant chez vous, décalant ainsi le moment où ils vont créer de la valeur et vous exposant à un risque de rupture de période d'essai plus élevé.
  • vos besoins en scale : est-ce que vous prévoyez, réellement, une croissance très rapide (ie : hyper croissance) de votre activité qui vous expose à des problématiques de performance et de scalabilité accrue ? Ce genre de cas est assez rare mais existe. Si vous pensez être dans un de cas mais n'avez pas de compétences techniques particulières, vous devriez vous faire accompagner par un expert dans ce domaine pour valider ce diagnostic. Si le cas est bien réel, les technologies que vous allez choisir peuvent avoir un impact immense sur votre capacité à passer à l'échelle dans quelques mois. Exemple : un hébergement chez un acteur de type PaaS (Heroku, Vercel, ...) peut être une excellente manière de démarrer pour abstraire certaines questions mais peut devenir un cauchemar en terme de prix si vous grandissez trop vite avant d'avoir eu le temps d'en sortir
  • le type d'actif technologique : dans certains cas, la valorisation de votre entreprise va dépendre fortement de l'actif technologique que vous construisez. Dans la majorité des entreprises, c'est la combinaison entre l'actif technologique et les actifs commerciaux et financiers (ie : vos contrats, votre chiffre d'affaires, votre taux de marge, ...) qui va déterminer la valorisation de votre entreprise. Mais dans certains cas d'entreprises très technologiques, la valeur de la société va être corrélée quasi exclusivement aux choix technologiques réalisés. Ces sociétés ont souvent une stratégie d'exit via une revente à un autre acteur qui saura trouver une justification financière à cet actif. Dans ce cas rare, choisir une technologie spécifique voire la développer est une des raisons d'être de la société. Ces entreprises sont en général créées par des experts Tech & Produit.
  • le cycle de vie de la société : plus globalement que le point précédent, savoir quel est le cycle de vie et la stratégie de sortie est un point qui est souvent oublié quand on choisit une stack technologique. Une startup prête à prendre tous les risques pour se positionner sur un marché avant une potentielle revente peut se permettre de faire des choix exotiques. A l'inverse, une société qui veut grandit de manière contenue et qui a pour vocation à devenir une PME devrait plutôt s'orienter vers des technologies plus matures sur lesquelles les risques sont plus faibles.

Qui doit porter ces choix ?

Une question primordiale est de voir qui doit porter le choix des technologies qui vont être utilisées dans votre entreprise. Cette question peut paraitre évidente de prime abord : seul un développeur peut faire un choix sur les technologies qu'il va utiliser pour développer votre produit. Néanmoins, comme décrit dans cet article, ces choix découlent d'une analyse fine de votre situation et de votre vision. Cette analyse doit non seulement être partagée avec votre référent technique (premier développeur, CTO, Technical Advisor, ...) mais doit en réalité être co-construit pour qu'il puisse challenger cette analyse et l'avoir complètement à l'esprit au moment de vous proposer ses choix.

C'est pour cette raison que je préconise de faire ce travail en 3 temps :

  • Analyse de la Société : cette phase se fait en Comité de Direction réduit avec les personnes qui portent la vision de l'entreprise et l'expert technique à même de faire ce type de choix. Tout ce qui est décrit dans cet article peut servir de guide à cette analyse mais vous pouvez bien sûr aller plus loin et faire intervenir d'autres participants : un Advisor qui est déjà passé par cette phase, une web agency avec qui vous travaillez déjà, des développeurs que vous êtes en train de recruter, un fond d'investissement si vous en avez déjà un, ...
  • Analyse des possibilités : dans cette étape, c'est votre expert technique qui prend le lead et qui va, en se basant sur son expérience et sur l'analyse du marché, faire une ou plusieurs propositions de stack technologique en détaillant les raisons du choix de chaque technologique qu'il pense être adéquat. Toute cette stack technologique ne sera pas forcément à mettre en place le premier jour mais donnera un guide à vos prochaines réflexions. Cette analyse permettra ensuite de vous focaliser sur votre création de valeur produit et business en passant moins de temps sur ces aspects purement techniques.
  • Présentation et décision : votre expert technique vous présente alors les options qu'il a retenues en vous expliquant bien les raisons de ces choix. Il est important que ces motifs soient bien compris et validés par l'ensemble de votre Comité de Direction car ils auront un impact potentiel sur chacun d'eux : sur la Direction Commerciale pour des demandes spécifiques de vos clients, sur la Direction Financière pour les coûts d'hébergement, sur la Direction des Ressources Humaines pour les questions liées au recrutement, ... Chacun doit donc être parfaitement en phase avec ces choix.

Principaux critères de choix

De mon expérience, la plus grande difficulté à gérer des équipes techniques vient du recrutement, de la fidélisation et de la motivation des équipes. Une équipe mal organisée car en sous-effectif ou qui n'est pas motivée sera un vrai centre de coûts (financier et en temps) alors qu'une équipe technique qui fonctionne doit impérativement être un centre de profit pour l'entreprise. Choisir ses technologies doit ainsi aller dans le sens de la construction d'une équipe fonctionnelle et en capacité d'anticiper les besoins de croissance et d'évolution de l'entreprise.

Dans ce cadre-là, un mélange doit se faire entre des technologies matures qui assurent une grande résilience à l'équipe tout en facilitant les futurs besoins en recrutement et des technologies plus récentes qui représentent des paris qu'il faut maitriser mais qui vont conserver la motivation des équipes. Il faut ainsi que votre expert technique arrive à différencier la "hype" créée par une technologie nouvelle des vrais gains qu'elle peut apporter à la vélocité de votre équipe. Le choix de cet expert technique (interne ou externe) devient ainsi un choix au moins aussi important que celui de cette stack technologique ou de vos premiers développeurs.