On ne peut plus aujourd’hui faire du business dans le digital sans comprendre un minimum les technologies web modernes. Pourquoi ? Parce que l’idée ne vaut que par sa réalisation et que la réalisation implique la technologie. Tout simplement.
Cet article s’adresse à des profils « business » n’ayant pas de background technique mais voulant développer / peaufiner leur culture tech. Si vous appartenez à cette catégorie de personnes, rassurez-vous, l’objectif n’est pas de vous transformer en techniciens aguerris mais de vous donner les clés de compréhension des technos web en 2020. Pour que vous compreniez enfin ce que les développeurs vous racontent.
Ce tour d’horizon des technologies web modernes, inspiré d’un bon article de Medium, comprend 6 sections. Chaque section couvre une famille de technologies.
Frontend (web)
Le frontend et le backend sont les deux faces d’une application web. Le frontend, c’est ce que voit l’utilisateur, le devant de la scène. Le backend, c’est l’infrastructure sous-jacente, les coulisses. Les technologies de frontend sont celles qui visent à construire une interface utilisateur (UI) et à délivrer une bonne expérience utilisateur (UX) sur le site web.
Du fait de la complexification des interfaces utilisateurs, il existe maintenant des développeurs spécialisés dans les technologies frontend. Le langage JavaScript (JS) est aujourd’hui le seul langage utilisé pour créer des interfaces utilisateurs de type dynamiques. Mais pour mettre en place des UI complexes, il faut utiliser ce qu’on appelle des frameworks JavaScript. Ce sont des bibliothèques de fonctions conçues en JavaScript qui permettent de construire des infrastructures frontend plus poussées.
Il y a 3 principaux frameworks JavaScript pour le développement frontend :
Chacun de ces frameworks et l’écosystème qui les entourent sont vraiment très différents les uns des autres, si bien que rares sont les développeurs frontend à maîtriser plus d’un framework.
Quel framework JS choisir ? Quel est le meilleur ? Je vous déconseille d’utiliser Google pour trouver une réponse, car il n’y a pas de réponse simple. En fait, tout dépend de ce que vous voulez faire :
- Si vous voulez construire en même temps une application web (un site web) et une application mobile, mieux vaut utiliser React.
- Si vous voulez avoir rapidement un prototype d’application web, privilégiez Vue.
- Si vous voulez une structure complexe et très définie plutôt qu’une structure souple, choisissez de préférence Angular.
- Si vous ne savez pas exactement ce que vous voulez, choisissez en fonction de la facilité ou non à trouver un développeur compétent. Mieux vaut un bon développeur Vue qu’un mauvais développeur React. Mais il faut savoir par contre que les développeurs React sont plus recherchés que les autres, et donc plus chers globalement.
Applications mobiles
Il existe deux approches possibles pour développer une application mobile. Il y a la bonne vieille méthode de développement (l’approche « native ») qui consiste à développer séparément l’application pour chaque plateforme (iOS et Android). L’autre approche consiste à utiliser un langage / framework cross-plateforme qui fonctionne avec le code natif de chaque plateforme.
Bien que la première approche existe depuis longtemps, les langages recommandés par les éditeurs de plateformes ont récemment changé. Google, qui édite le système d’exploitation Android, recommande maintenant d’utiliser le langage Kotlin plutôt que Java. Apple recommande maintenant Swift plutôt qu’Objective C pour créer des applications iOS. Cela ne vous interdit pas d’utiliser les anciens langages pour construire votre application mobile – surtout qu’il existe plus de développeurs maîtrisant ces langages classiques.
La deuxième approche permet de construire une application mobile plus rapidement et pour un coût plus abordable. Mais la performance des applications s’en ressent. Les interfaces sont parfois plus lentes, le poids des applications a tendance à être plus important. Malgré tout, c’est vraiment une approche plus simple. Nous aurions tendance à vous la recommander, sauf si votre application a besoin d’être super-performante et d’utiliser des fonctionnalités hardware poussées.
Le langage le plus utilisé pour développer une application mobile en cross-plateforme est le framework React Native, développé par Facebook. Si vous avez construit votre site web avec React (et Node.js pour le backend), il est possible que les développeurs avec lesquels vous avez travaillé puissent réaliser votre application mobile en React Native. Si vous avez des ressources limitées, c’est un point intéressant. Vous pouvez aussi utiliser Flutter, une alternative à React Native développée par Google. Ce framework utilise le langage Dart, qui est assez peu utilisé…du coup trouver un développeur Flutter n’est pas toujours simple. Flutter est une option à envisager si vous voulez une application mobile très performante mais que vous voulez utiliser l’approche cross-plateforme pour économiser de l’argent.
Backend (REST API)
Choisir une technologie backend n’est pas évident. Java est la technologie backend historique. D’autres acteurs sont apparus, comme Node.js qui attire beaucoup de développeurs pour sa relative simplicité et les temps de développement réduits que cette techno permet. Le développement backend couvre une grande variété de produits, pas uniquement les applications web. Nous allons ici uniquement nous intéresser aux technologies nécessaires pour construire une REST API.
Une REST API désigne un serveur qui extrait les données à partir de sources (une base de données par exemple) et envoie ensuite cette donnée à un navigateur web ou à une application mobile utilisant des formats de données bien définis. Contrairement à l’approche ancienne – où le serveur était responsable à la fois des données et de l’UI – une REST API ne s’occupe que de la donnée tandis que les développeurs frontend et les frameworks JS sont responsables de l’UI (comme nous l’avons vu tout à l’heure).
Voici les principales technologies utilisées aujourd’hui pour construire une REST API :
Node.js est la technologie la plus rapide pour construire une REST API – et c’est en même temps l’environnement le plus puissant. En utilisant Node.js, les développements backend peuvent être partagés aux développeurs frontend, pour la simple et bonne raison que l’environnement Node.js utilise le langage JavaScript. Si vous n’avez aucune préférence a priori pour un langage ou un autre, Node.js est clairement la meilleure option.
Autre option : Java. Java est très différent de JavaScript malgré la proximité des noms. Java impose une architecture plus stricte et réduit a priori le risque d’erreurs de programmation. Mais cela a un coût. Java est un langage complexe. Les développeurs Java sont les plus chers ! Etant donnée la complexité de ce langage, Java n’a pas d’intérêt si vous voulez créer une REST API simple.
Troisième option : Python. Ce langage est beaucoup utilisé en Data Analyse, pour du machine learning, de l’intelligence artificielle, etc. Peu de personnes utilisent Python pour construire leur REST API…mais malgré tout quelques-uns le font ! Si vous avez besoin de Python pour construire d’autres parties de votre produit, personne ne vous blâmera si vous utilisez Python pour votre REST API.
Pour être tout à fait objectif, il faut aussi mentionner C#, un langage développé par Microsoft. Beaucoup de grandes entreprises l’utilisent. Ce n’est certainement pas la meilleure option pour une startup mais il existe beaucoup de développeurs C# capables de vous développer une bonne REST API. Le problème, c’est que l’infrastructure basée sur Windows est largement plus chère qu’une infrastructure basée sur Linux. Vous pouvez c’est vrai utiliser C# avec Linux, mais à vos risques et périls !
Malheureusement, vous ne devez pas seulement choisir un langage, mais, comme pour le frontend, vous devez aussi choisir un framework. Voici les principaux frameworks pour chaque langage :
- Node.js : Express ; Koa
- Java : Spring Boot ; Vert.x
- Python : Django ; Flask
Un développeur maîtrise rarement plusieurs frameworks sur le bout des doigts.
Contactez Cartelis
pour enfin capitaliser sur vos données clients.
Cartelis vous accompagne dans le cadrage et le déploiement d'une stratégie data et CRM vraiment impactante.
Analyse client, Choix des outils, Pilotage projet et Accompagnement opérationnel.
Prendre contact avec CartelisBases de données
La base de données est le coeur d’un produit digital. Il est donc essentiel de faire le bon choix de technologies. Avant de choisir un éditeur de base de données, vous devez d’abord choisir le type de base de données que vous voulez : une base relationnelle (SQL) ou une base non-relationnelle (NoSQL). Il y a eu beaucoup de battage autour des bases NoSQL il y a quelques années, donc inutile de chercher dans Google quelle est la meilleure solution ! Les bases NoSQL ne sont pas conçues pour créer des Data Warehouses. Elles sont utilisées pour des projets précis ou pour gérer des données non-structurées.
Les bases de données ne sont pas toutes gratuites. Les deux principaux éditeurs commerciaux proposant une solution de BDD relationnelle sont Microsoft SQL et Oracle. Ils proposent de très bons outils pour designer et gérer une base de données – mais aujourd’hui il existe aussi de très bons outils gratuits.
Il existe deux principales options gratuites pour créer une base de données relationnelle :
Ce sont deux outils à peu près identiques. Concurrence oblige, chaque éditeur copie les fonctionnalités de l’autre. PostgreSQL est souvent choisi par les développeurs car cet outil propose aussi les meilleures fonctionnalités pour travailler sur des BDD NoSQL. Mais MySQL propose à notre avis de meilleurs outils pour gérer les données et la base de données elle-même. Vous avez peut-être aussi entendu parler de MariaDB. C’est une technologie qui reste encore largement moins utilisée que les deux autres.
Une fois que vous avez choisi un base de données, vous devez décider comment la faire communiquer avec le backend. L’option basique consiste à utiliser du SQL. C’est efficace mais certains trouvent cette solution trop complexe et optent pour d’autres approches. L’ORM est la plus populaire. Il s’agit d’un acronyme pour Object-Relational Mapping. C’est une approche qui évite d’avoir à utiliser les requêtes SQL. L’ORM est relativement simple à utiliser pour les utilisations basiques mais devient très vite compliqué si vous avez des données complexes. En général, les développeurs déconseillent d’utiliser ORM et préfère le SQL natif.
Quelques mots malgré tout des bases non-relationnelles, NoSQL. Si vous voulez stocker des données non-structurées, vous pouvez sans hésitation utiliser MongoDB, la référence en matière de BDD NoSQL. Si vous souhaitez stocker des données en cache, Redis est à envisager. Les bases NoSQL sont un sujet complexe, inutile d’aller plus loin. Seulement, si vos développeurs vous proposent d’utiliser une base NoSQL, posez-leur des questions, cherchez à comprendre les raisons de leur proposition. Vous pouvez être tenté d’utiliser une base NoSQL si, par exemple, vous vendez des produits de nature très différentes avec des fonctionnalités qui se chevauchent, mais il est quand même préférable de mettre les core data dans une base SQL
Hébergement (Cloud)
Trouver un hébergeur peut sembler relativement simple. Mais ce n’est plus vrai aujourd’hui car choisir une solution d’hébergement cloud signifie non seulement externaliser des ressources serveurs et de la puissance de calcul, mais aussi tout ce qui concerne la scalabilité, la résilience et last but not least la sécurité. Le choix est d’autant plus complexe que les hébergeurs sont devenus très forts dans l’art de marketer des nouveaux services qui semblent incroyables en apparence alors qu’ils ne servent pas à grand-chose ! (ou en tous cas qui ont peu de chances de vous servir à vous).
Au niveau mondial, les 4 principaux acteurs sont :
A côté de ces mastodontes, il y a bien sûr tous les hébergeurs de plus petite taille, mais ils offrent bien moins d’outils et de services. Ils peuvent être préférés pour des raisons légales ou si vous préférez héberger vos données localement (en France, en Europe).
Les trois premiers acteurs de la liste offrent un très large éventail de services avec des structures tarifaires assez complexes. Mais vous n’aurez jamais besoin d’utiliser 95% de leurs services. Si vous débutez, je vous recommande Digital Ocean. Cet éditeur propose une interface ergonomique, des outils simples à utiliser et offre pratiquement tout ce dont une startup ou une PME a besoin. Si vous préférez pour un des Big 3, je vous conseille Amazon. C’est plus cher que Google, mais les outils et l’interface sont meilleurs. Je connais moins Azure, qui est construit avec une technologie de niche (Microsoft) et semble ne pas présenter d’avantages clairs par rapport à Amazon et Google.
Pour être efficace et compétitif aujourd’hui, vous ne devez pas simplement outsourcer l’infrastructure mais aussi les services business (l’emailing par exemple). Ces services étaient auparavant internalisés mais sont aujourd’hui en général externalisés. Il y a énormément d’acteurs proposant des services business dans le cloud aujourd’hui. Pour en savoir plus, nous vous renvoyons vers nos comparatifs : Comparatif des logiciels de Marketing Automation, Comparatif des CRM B2B, etc.
Microservices
Les gens familiers avec l’univers moderne du développement de logiciels ont sans doute déjà entendu parler du mot « microservices ». Il s’agit essentiellement d’une approche d’architecture visant à améliorer la scalabilité et la résilience de votre système. La scalabilité et la résilience sont évidemment de très bonnes choses, mais ce que l’on ne dit pas toujours clairement c’est le coût que les microservices représentent un coût. Ce coût peut être très élevé.
Si vous souhaitez utiliser des microservices, vous serez confronté à un premier challenge si vous décidez d’utiliser un service d’authentification. Le problème, c’est que l’authentification est utilisée par tous les microservices. Le partage de l’authentification entre les microservices est un sujet très complexe. Vous ferez face à un deuxième obstacle si vous avez des transactions qui enjambent plusieurs microservices. Ce qui est le plus simple quand on utilise un seul service devient une prise de tête quand on utilise des microservices. Par conséquence, sauf si vous avez une équipe solide (et bien payée) d’ingénieurs backend et frontend ainsi qu’une équipe DevOps, je vous recommande chaudement de ne pas utiliser de microservices. Au moins au début. Mieux vaut avoir un seul service performant que des microservices qui fonctionnent mal. Surtout que vous pouvez gérer très bien la scalabilité et la résilience en utilisant un service d’orchestration des applications comme Docker ou Kubernetes. Si vous rencontrez plus tard un problème de performance avec ces outils, vous pourrez toujours basculer certains services sur un microservice.
Voilà, nous arrivons au terme de ce panorama général des technologies web modernes. Chaque section est un monde en soi et pourrait faire l’objet d’un article dédié. Mais j’espère que cet article de synthèse vous aura permis d’acquérir une vision globale du paysage technologique et donner l’envie d’aller plus loin !
Cet article est de loin le plus complet que j’ai pu lire sur internet concernant les technos web modernes.
Merci encore.
Merci beaucoup Cartelis pour votre explication.