Tout projet à impact technologique qui démarre déclenche un ensemble de prises de décisions, de choix, de réflexions, avec pour objectif de franchir les étapes successives et aboutir au succès. Parmi ces choix, les technologies que l’on va décider d’utiliser, la façon dont on va les décliner et la philosophie sur laquelle on s’appuie, ont bien sûr une place essentielle.
Copyright Tilkal SAS
Choix technologiques : un impact global sur l’entreprise
Entre l’audace d’utiliser une technologie émergente, prometteuse mais non prouvée et la décision de baser les développements sur le langage le plus fréquemment utilisé, les impacts varient et exposent certaines valeurs qui comptent pour les fondateurs du projet.
Ainsi, l’utilisation d’un langage unique peut faciliter le partage de la connaissance et permettre à chacun d’agir sur n’importe quel aspect du projet (le full stack pour tous). Le choix d’une bibliothèque peu connue impactera quant à elle le recrutement : on trouvera plus facilement des personnes avec une expertise sur des outils différents, plus utilisés. A contrario on rencontrera des candidats qui ne souhaitent finalement pas évoluer vers d’autres technologies que celles qu’ils maitrisent déjà… découverte qui peut être un mal pour un bien pour le recruteur. L’intérêt pour le projet, plutôt que pour les technologies utilisées pour le réaliser, a toujours été le principal critère pour les recrutements chez Tilkal. L’adhésion à la philosophie du projet, un cerveau bien fait et la volonté d’élargir ses compétences permettront de s’adapter et profiteront bien plus au projet et à la recrue qu’une simple adéquation technologique.
Au moment de faire ces choix, quels sont les éléments permettant de s’orienter ?
Tout dépend de la situation. Pour une première aventure, ses propres compétences techniques seront un premier filtre. On pourra s’aider d’une étude de marché pour choisir le langage ou la bibliothèque qui semblent les plus adéquats pour commencer, l’environnement qui semble le plus simple à mettre en œuvre : auto-hébergement ? AWS, Azure ou Google Cloud Platform ?
Aujourd’hui le choix est vaste, mais il faut malgré tout éviter le piège de la technologie Flavor of the month, en s’aidant de certains indicateurs. La traction par exemple : qui pousse l’outil, le langage ou la bibliothèque ciblée (équipe reconnue ? documentation de qualité ? livraisons fréquentes ?), existe-il une communauté autour de cette technologie qui apportera de l’aide en cas de blocage ? Doit-on laisser ses positions philosophiques guider ces choix ? Un anti Google s’autorisera-t-il à utiliser angular, un anti Facebook react ?
Dans tous les cas, et sauf exception, il sera plus efficace de s’appuyer sur un produit reconnu que de tout refaire soit même (le fameux écueil du fait maison) : tout le monde n’a pas les besoins de Facebook, et réécrire PHP n’est pas forcément nécessaire, surtout pour démarrer ! Réécrire des primitives de crypto est a priori une mauvaise idée, sauf si, justement, le projet est d’apporter des nouveautés dans le domaine (auquel cas on est censé savoir ce que l’on fait…).
Pour les non primo-entrepreneurs, l’expérience précédente va avoir un impact significatif. Les technologies précédemment utilisées peuvent être un bon choix : la maitrise de celles-ci permettra de se concentrer sur le métier et le fonctionnel, au moins dans un premier temps, voire plus si aucun blocage ne se présente. Mais on peut aussi se retrouver dans la situation du plus jamais ça : traumatisé par une précédente aventure rendue difficile par des mauvais choix, et alors vouloir reconsidérer la stack utilisée. Le souvenir douloureux d’un monolithe en Java opéré à la main pourra motiver l’utilisation de micro-services serverless par exemple.
Il reste un sujet de choix technologique impactant, surtout en fonction de l’expérience des personnes dans l’équipe : celui du matériel, des systèmes d’exploitation et des environnements de développement utilisés par l’équipe. PC ou Mac ? Windows ou Linux ? vi ou IntelliJ IDEA ? Pour certains, en fonction de leurs habitudes, cela peut impacter la productivité. Heureusement aujourd’hui, la plupart des IDE tournent sous les trois plates-formes, et cela ne représente donc plus une réelle contrainte.
Alors qu’en est-il des choix faits par Tilkal pour développer ses produits ?
Tilkal développe et opère des outils permettant à ses clients de mettre en place une traçabilité bout en bout sur les produits qu’ils fabriquent, transportent ou distribuent. Pour assurer l’auditabilité des données collectées, nous utilisons des technologies type blockchain, pas pour leur fonctionnalité de crypto-monnaie, mais uniquement pour le coté registre distribué, afin de permettre à tous les acteurs du réseau d’être autonomes dans la fourniture de preuve sur les évènements déclarés. Nous avons choisi d’utiliser MultiChain, moteur de blockchain simple à mettre en œuvre et capable des performances nécessaires au contexte « haut volume » de la traçabilité des supply chains.
Pour le reste de la plate-forme, l’idée conductrice était de pouvoir utiliser quasiment les mêmes technologies coté front et back, afin de permettre à tous de participer à la construction de l’ensemble du produit. JavaScript (puis TypeScript) nous a semblé être le bon choix, une évidence côté front, et une option tout à fait crédible coté back avec Node.js exécuté dans des lambdas AWS.
D’ailleurs, JavaScript coté serveur n’a rien de nouveau, les anciens de Netscape le savent bien ! Nous utilisons Aurelia.io qui nous a semblé être une bibliothèque facile à prendre en main, avec peu de connaissances JavaScript au démarrage, et qui respectait certains des principes forgés au cours de nos précédentes expériences. Certaines parties front ont été conçues à l’aide de Dojo 2 qui nous paraissait être un bon choix pour développer des applications légères et à ouverture rapide, choix remis en cause par l’adoption de Ionic Framework pour les versions suivantes de ces applications. Cette bibliothèque, découverte au moment de fournir une application mobile native, nous a paru pertinente au-delà de l’aspect mobile natif.
Nous exploitons beaucoup les services AWS, ainsi que quelques services AlibabaCloud spécifiquement pour la Chine. Le choix AWS date de notre expérience précédente à Matthieu et moi -choix qui à l’époque (2008) ressemblait plutôt à un pari ! Un choix non remis en cause, surement pour capitaliser sur les connaissances acquises autour de ces produits, mais aussi parce que l’on pense que les autres plates-formes n’offrent pas encore le même niveau de fonctionnalité et de maturité.
Bien sûr c’est de moins en moins vrai, les principaux concurrents (Microsoft Azure, Google Cloud Platform et AlibabaCloud) s’efforçant de se mettre à niveau, voire de dépasser AWS sur certains aspects (data sur GCP par exemple). C’est un choix très impactant, la question du vendor lock-in pouvant se poser : nous assumons un lock-in minimal, que nous conservons voire diminuons au gré des évolutions de notre plateforme, afin d’être prêts pour de futures offres de portabilité multi-cloud… voire pour utiliser un futur cloud européen suffisamment équivalent à AWS !
Finalement, le choix le plus important c’est celui de la flexibilité : être prêts à remettre en cause certaines décisions, pour permettre à son produit de s’améliorer, pour éviter de s’enfermer dans une technologie dépassée (hello Flash). Position pas évidente vue la vitesse à laquelle les technologies évoluent actuellement.
Un article de Sébastien Gaïde, co-fondateur et CTO de Tilkal