Bien démarrer le développement d'une application web from scratch

Publié le par

Introduction

La difficulté n'est pas de mettre en place une solution technique, car n'importe qui peut faire une étude de marché, puis décider de la solution à adopter, mais plutôt d'anticiper son évolution et ses coûts futurs.

Selon le profil de la personne en charge de choisir la stack technique des projets web de l'entreprise, un décideur non technique se fiera généralement à la pratique et à la tendance du marché, alors qu'un décideur technique s'appuiera sur ce qu'il sait maîtriser et faire de mieux. En ce sens, quelque soit le profil du décideur, son choix sera tout à fait justifié, logique et rassurant. Cependant, a-t-il vraiment pris en compte tous les paramètres ? A-t-il mesurer les conséquences et l'enjeu de ses décisions ?

Effectivement, vous l'aurez compris, on ne se lance pas tête baissée sur le développement d'une application web sans avoir pris consciences des risques techniques, humains, et financiers.

Ce guide n'a pas la prétention de proposer la solution technique universelle, ni de vous dicter comment vous devriez faire une application web from scratch, car il y a trop de paramètres et de possibilités liés à chaque projet, budget, situation et entreprise, mais plutôt vous aider à voir les choses sous un angle différent afin que votre choix technique et pratique répondent au plus près à votre objectif.

Que vous soyez à l'état de l'idée, une startup ou une entreprise internationale, le problème reste le même : quel est le choix technique et pratique pour bien démarrer votre application web from scratch ?

Pour commencer, ayez à l'esprit que rien n'est gratuit, rien n'est facile, et rien n'est acquis... Et que l'arrogance, la prétention et l'excès de confiance sont fréquents dans le milieu de la technique. Par conséquent, la prudence et l'expérience restent les meilleurs atouts pour bien débuter le développement d'une application web. Veuillez noter que tout résultat, succès comme échec, est le fruit de travail, d'audace et de persévérance.

Partant de ces quelques principes de base, par quoi commence-t-on, et surtout quels sont les critères à prendre en compte qui vont vous aider à la décision et à bien préparer votre projet ?

Le besoin du from scratch

Suite à un besoin précis et pour développer votre activité, vous avez besoin d'une application web.

Pour des raisons stratégiques, financières ou parce-qu'il n'existe pas de solution déjà toute faite sur le marché, vous avez décidé de la développer from scratch, c'est-à-dire à partir de zéro.

Contrairement à ce que l'on pourrait penser, c'est une décision importante, et cette responsabilité est lourde de conséquence. En effet, développer une application de A à Z et faire du sur-mesure nécessite un temps non négligeable. Pendant la phase de développement, votre activité sera immobilisée, ou du moins sera au ralentie, et cela au profit de vos concurrents.

Le projet devient l'objectif à atteindre. Il est la raison d'être d'une activité, et son existence n'a de sens que s'il est utile et réussi.

Une application naît pour répondre à un besoin (il y a un investissement : « rien n'est gratuit »). Elle est maintenue et évolue en fonction de nouveaux besoins (cela demande du travail : « rien n'est facile »). Puis enfin, elle meurt lorsqu'elle n'est plus utile (fin de vie de l'application : « rien n'est acquis »).

Le MVP

Le MVP (Minimum Viable Product) désigne le produit minimum viable. C'est la première version de l'application web qui permet aux clients de profiter des premières fonctionnalités, mais aussi d'obtenir un maximum de retours utilisateur.

« Anticipation », « Déploiement » et « Agilité » forment les 3 piliers d'un développement from scratch, sous l'acronyme ADA :

  1. L'Anticipation, à partir d'une fonctionnalité ou d'un besoin, consiste à prévoir les actions et les besoins du client. Pour cela, le recueil d'informations est cruciale, donc le retour client. C'est ce qui va permettre de prendre les décisions sur l'orientation des futures fonctionnalités et des priorités ;
  2. Le Déploiement désigne la capacité à développer/produire et à délivrer les fonctionnalités dans un délai le plus court possible. Cela est étroitement lié aux ressources (équipe) et à l'environnement technique ;
  3. L'Agilité est la capacité de s'adapter plus facilement aux changements. Pour cela, elle se repose sur une méthodologie prenant en compte les points forts et les points faibles de chaque membre de l'équipe. Elle y établit donc une relation de confiance, tout en conservant une remise en question sur le développement et les fonctionnalités, dans un processus d'amélioration continue.

Pour les activités qui peuvent se le permettre, il existe également le minimum du MVP. Par exemple pour une activité de service, telle que le courtage en assurance, il est intéressant de commencer par la mise en ligne d'un simple site vitrine avec un formulaire de contact. Cette pratique permet d'annoncer son existence, ses services, ses avantages, mais aussi de développer sa visibilité sur internet et sur les réseaux sociaux. L'acquisition des premiers clients vont aider à définir l'orientation et la priorité de départ : d'abord le module de l'assurance auto, puis celui de l'habitation, etc.

Les fondations d'une application web

Il existe 3 éléments clés formant les fondations d'une application web :

  1. La connaissance : c'est le savoir-faire permettant de concrétiser le projet web ;
  2. L'argent : c'est le moyen pour faire vivre, maintenir et faire évoluer le projet web ;
  3. Le temps : limite les étapes, valide les objectifs, et détermine la durée de vie du projet web.

Ces 3 éléments sont cruciaux pour lancer un projet web. Ce sont des leviers sur lesquels vous pouvez jouer pour atteindre vos objectifs et obtenir un certain degrés de qualité de service. Les posséder tous les 3 augmentent clairement vos chances de réussite, mais ce n'est pas une garantie car ces éléments varient dans le temps.

Pour pouvoir démarrer un projet, il suffit d'avoir au moins 2 de ces 3 éléments clés :

  1. connaissance et argent : les bonnes compétences font gagner du temps, et l'argent peut acheter du temps (en achetant des services) et de la connaissance (en achetant des ressources qui elles-même vont faire gagner du temps) ;
  2. connaissance et temps : la connaissance produit les services pour gagner de l'argent, et le temps permet de trouver de l'argent (investisseurs), mais également de la connaissance (ressources) ;
  3. argent et temps : l'argent achète les compétences, donc la connaissance. Le temps permet aussi d'attendre la disponibilité de la bonne ressource et/ou l'acquisition de nouvelles compétences.

Avec la configuration de 2 éléments clés, le risque est plus élevé sachant que ces éléments ne sont pas illimités, d'autant plus que le facteur humain n'est pas fiable (turn-over, maladie, etc.), quelque soit le niveau hiérarchique de prise de décision ou de production dans l'entreprise.

La connaissance

La connaissance est l'élément le plus important, car sans elle, l'application web ne pourrait pas se concrétiser. C'est l'humain qui détient cette connaissance. Par conséquent, l'humain doit être au centre de toutes les attentions.

L'humain est une ressource, et l'erreur est de croire que cette ressource est en abondance quoiqu'en disent les journaux et les statistiques. Si la tendance de ces résultats est vraie, cela ne signifie pas pour autant que vous allez obtenir la ressource recherchée et surtout au moment où vous le souhaitez.

Comme vous pouvez vous en douter, les meilleures ressources ne sont généralement pas disponibles, ce qui les rend extrêmement rares, donc chère, surtout si elles détiennent la connaissance et l'expérience dont vous avez impérativement besoin.

L'argent

L'argent n'est qu'un moyen pour atteindre vos objectifs. Il vous permet d'acquérir les ressources et services dont vous avez besoin pour le développement de l'application web. L'argent achète la connaissance, mais également le temps. Cela signifie que plus vous avez de ressources, et plus ces dernières vous ferons gagner du temps.

L'argent est précieux, car sans cela, vous n'aurez probablement pas la connaissance, ou la possibilité d'aller jusqu'au bout de l'objectif fixé.

Le temps

Le temps est comme un train qui ne s'arrête jamais. Soit il vous amène à destination plus ou moins rapidement et/ou en bonne santé (succès), soit vous n'arrivez jamais à destination (échec).

L'argent achète le temps, ce qui signifie que vous arriverez probablement à destination plus vite, mais ce n'est pas une garantie. Car n'oubliez pas, rien n'est acquis.

La connaissance, quant à elle, est un indicateur sur l'état de votre santé à l'arrivée : fatigué, en forme, motivé, énervé, etc. Cela représente effectivement la qualité de l'application web.

Avec le temps, vous pouvez trouver la connaissance (recrutement ou auto-formation), mais également l'argent (investissement). Cependant, si le temps est illimité dans l'absolu, il ne l'est par contre pas pour une application web qui a un temps d'expiration pour son développement, puis une durée de vie limitée, pour la simple et bonne raison que la concurrence n'attend pas.

Si vous ne sortez pas votre application web à temps, d'autres le feront à votre place. Le temps, c'est la concurrence.

La technologie

Toutes les routes mènent à Rome, mais il vous appartient de choisir le trajet le plus rapide, le plus sûr, et le plus confortable pour y arriver.

Rappelons que l'informatique n'est qu'un outil pour traiter des tâches répétitives. L'objectif est de vous faire gagner du temps, et donc de l'argent, car le temps c'est de l'argent. Si ce n'est pas le cas, alors une application web ne vous sera d'aucune utilité, et deviendra inévitablement une charge.

Pour créer une application web, les technologies web de base devront être maîtrisées :

  1. le protocole HTTP pour les échanges de contenu entre le navigateur et le serveur ;
  2. les langages du côté client à connaître impérativement :
    1. le langage de balisage HTML pour structurer le contenu ;
    2. le CSS pour décorer et gérer l'apparence des page web ;
    3. le JavaScript pour rendre dynamique et interactif les pages web. Avec l'avènement de NodeJS, le JavaScript est aussi utilisé du côté serveur ;
  3. les langages du côté serveur au choix : Java, Python, PHP, NodeJS, Go, #C, etc.

Choisir une technologie web revient à choisir principalement un langage du côté serveur, avec son environnement et ses pratiques.

Il faut savoir qu'un langage n'est qu'un outil ou un moyen de concrétisation. Et on ne choisit pas un outil parce-qu'il est à la mode ou parce-que tout le monde l'utilise. On le choisit parce-qu'il est le plus adapté au besoin, et il doit être utilisé pour ce qu'il sait faire de mieux. C'est une évidence que beaucoup oublient en faveur du marketing des nouvelles technologies et de la mode.

Le framework

Un framework désigne un ensemble de composants logiciels qui :

  1. forme le squelette et l'architecture de l'application web ;
  2. permet de structurer le code source ;
  3. vise la productivité maximale en facilitant le travail du développeur.

Le choix d'un framework est étroitement lié à la technologie, et donc au langage. Par exemple Java d'Oracle, PHP de Zend, #C de Microsoft, etc.

Comme son nom l'indique, un framework est un cadre de travail, comme un atelier de fabrication. Donc si vous ne fabriquez que des chaises, préférez un atelier dédié uniquement à la fabrication de chaises, et qui soit adapté à votre façon de travailler pour une productivité maximale. Bien qu'un atelier multifonction (chaises, tables, meubles, etc.) pourrait vous être utile, posez-vous la question : est-ce qu'un jour, vous allez fabriquer autre chose que des chaises ?

Si c'est dans un futur proche et que c'est une certitude, alors l'atelier multifonction pourrait être intéressant. Dans le cas contraire, concentrez-vous sur la fabrication de chaises pour le moment, puis en temps voulu, vous pourrez toujours acquérir un nouvel atelier spécialisé pour la fabrication de tables par exemple.

Finalement le choix d'un cadre de travail n'est pas si simple. Sur le marché, il existe des frameworks plus ou moins lourds, faciles à maîtriser, et adaptés à votre activité et/ou à votre façon de travailler. Choisir un framework connu et tendance, c'est le choisir pour de mauvaise raison, bien que cela puisse être rassurant, car on se dit « Puisque tout le monde l'utilise, ça ne peut être que bien ».

Le décideur doit tenir compte d'un tas de facteurs (stratégiques, financiers, ressources, délais, etc.) avant de s'engager sur une stack technique. Qu'il en assume ou pas ce choix, cela ne changera rien lorsque vous vous rendrez compte que la voie empruntée n'était pas la bonne ou la meilleure, et qu'au final cela s'avère être un obstacle dans votre scale-up. Mais qui ne fait pas d'erreur (rien n'est facile, rien n'est acquis) ? Si c'est le cas, considérez cette expérience très enrichissante (rien n'est gratuit), car vous ne ferez pas 2 fois la même erreur. D'ailleurs, c'est la cause de nombreuses refontes, qui font perdre du temps et de l'argent.

Enfin, sachez qu'un framework n'est qu'une partie de la solution à votre activité. Si tous les constructeurs automobiles fabriquent des voitures, ils ont aussi tous développé leur propre technologie et méthodologie. Et ceci est également vrai pour un framework. Par conséquent, il vous faudra certainement y rajouter une couche technique personnalisée. Certains pourraient associer cette dernière avec l'avance technologique, car elle permet à l'entreprise de produire plus et plus vite que ses concurrents.

Comme tout outil, le framework n'est pas une obligation, mais il est recommandé. Il peut être fait maison. Quelque soit le choix du framework ou de la solution technique (ex : no-code), le principal est d'avoir une application web qui répond aux attentes de vos clients et/ou utilisateurs, pour gagner de l'argent et du temps.

La méthodologie et gestion de projet

Tout comme le framework, il existe une multitude de méthodologie. Parmi les plus connues :

  1. la méthode traditionnelle : un cahier des charges détaillé est obligatoire, et il n'y a pas de place pour les imprévus. Les délais doivent être respectés, et les livrables conformes au cahier des charges. Aujourd'hui, cette pratique est totalement dépassée ;
  2. la méthode agile : cette méthode s'adapte aux projets en perpétuel évolution. Les besoins du client sont au centre des priorités et nécessite par conséquent une équipe réactive. Les retours, les ajustements et les évolutions sont possibles à tout moment. Le client pilote et décide de l'orientation que doit prendre le projet. Cette méthode est de loin la plus pratiquée ;
  3. la méthode adaptative : elle est pratiquée sur des projets en situation de changement continuel dû à de nombreux facteurs et variables : compétence de l'équipe, turn-over, technologie utilisée, implication du client, climat économique, les coûts, les risques, la durée, etc. L'approche adaptative s'adapte constamment à ces différentes variables en faisant preuve de créativité. Cette méthode complète la méthode agile, mais nécessite une anticipation avancée et une extrême agilité.

Vous pourrez trouver également votre bonheur dans d'autres méthodes de gestion de projet : la méthode du chemin critique (Critical Path Method), PERT, PRINCE2, Lean Management, Six Sigma, SCRUM, KANBAN, Extreme Agility, Extreme Programming, PRISM, Waterfall, PMBOK, Process-Based Project Management, Extreme Projet Management, etc.

Si le framework répond à « quoi faire », la méthodologie répond à « comment le faire et quand le faire » en optimisant la productivité. Il arrive que le choix technologique (framework) et celui de la méthodologie soient incompatibles. Par exemple, vous demandez à votre équipe d'être très réactive (méthode agile) alors que l'environnement technique (framework) est lourd, et ne permet pas des livraisons rapides.

Prenez conscience que la méthodologie n'est qu'une ligne directrice. Suivre à la lettre les directives et respecter strictement les cérémonies peuvent être contre-productif, d'autant plus que les développeurs ne sont pas des robots. Trop de variables entrent en jeu : projet, technologie, humain, client, concurrence, stratégie, politique, climat économique, etc.

Au final, comme c'est l'équipe de développement qui produit, alors pourquoi devrait-elle s'adapter ou se plier à une méthode en particulier ? Et pourquoi ne choisira-t-elle pas elle-même sa propre méthodologie en fonction de sa façon de travailler, de ses compétences, de ses motivations et de sa capacité à produire ?

Si nous remettons les choses à leur place, il serait plus judicieux de s'inspirer du meilleur de toutes les méthodologies, et de ne retenir que les pratiques efficaces à l'image de l'équipe. Comprenez que ce n'est pas la méthode qui fait l'équipe, mais que c'est l'équipe qui fait la méthode. Appuyez-vous sur l'expérience de chacun et privilégiez la communication. N'ayez pas peur de ne pas pratiquer une méthode connue ou d'inventer votre propre méthode, car ça sera votre choix, et c'est aussi une méthode. Le principal, c'est de ne pas perdre de vue votre objectif : fournir du service de qualité le plus rapidement possible, et satisfaire les utilisateurs (vos clients).

L'équipe de développement

L'équipe de développement se compose généralement de plusieurs personnes, mais une seule personne peut suffire pour démarrer un projet.

La présence d'un lead developer ou d'un CTO, selon le besoin et la taille de l'entreprise, est fortement recommandée. Cette personne aura les responsabilités suivantes :

  1. mettre en place la stack technique ;
  2. s'assurer du respect des normes et standards ;
  3. être le référent technique ;
  4. faire de la revue de code ;
  5. être le garant de la qualité ;
  6. former et faire monter en compétence l'équipe ;
  7. motiver et challenger l'équipe ;
  8. organiser et faciliter l'environnement de travail ;
  9. être un modèle et une inspiration (avec humilité).

La réalisation d'une application web fait appel à plusieurs compétences :

  1. la définition de la charte graphique, le design, l'UX ;
  2. le développement front (navigateur) et l'UI (User Interface) ;
  3. le développement back (serveur) et logique métier ;
  4. l'administration des données (base de données, big data) ;
  5. la gestion des serveurs (serveur, cloud) ;
  6. la sécurité du réseau.

L'idéal serait d'avoir une équipe constituée d'une personne par compétence. Mais comme une personne peut posséder plusieurs compétences, et que certaines compétences n'interviennent qu'en début du projet (ex : design, installation et configuration du serveur d'application et de la base de données), alors le nombre de personnes peut être réduit à un strict minimum : le développeur front et le développeur back. Ces derniers peuvent aussi être remplacés par un développeur fullstack (front + back).

Une équipe de développement doit couvrir toutes les compétences pour être agile et être totalement indépendante. Si toutes les compétences sont présentes, et que le besoin d'augmenter la productivité se fait ressentir, alors il suffira d'ajouter une nouvelle ressource ayant la compétence souhaitée. Cependant, ne soyez pas dans l'erreur de croire que vous aurez la ressource au moment où vous en avez besoin. Le temps de la recherche et du recrutement n'est pas négligeable. Donc tout est question d'anticipation.

Le CTO

Le CTO est un décideur et un stratège de l'innovation. Il fait de la veille technologique et s'implique dans la R&D. Par conséquent, il a une connaissance approfondie des NTIC et du management du risque. Il est aussi expert dans la gestion de projets transverses.

En principe, il ne participe plus au développement d'application, car ses responsabilités ne lui laissent plus le temps. Mais ça, c'est dans les grandes structures avec plus de 20 personnes à manager. Et par conséquent, il perd naturellement de sa technicité en faveur des activités de gestion et de management.

Avec la montée des startups, il devient fréquent qu'un CTO se (re)mette à coder. C'est la raison pour laquelle il est souvent confondu avec le Lead Developer.

Dans ce cas précis, pour une startup qui recherche son CTO, il est important de prendre en compte la compétence dominante du CTO. En effet, si la startup a besoin de développer une plateforme web, il serait plus logique de choisir un CTO ayant le profil développeur fullstack, qu'un profil par exemple expert en administration et sécurité réseau.

Chaque CTO est unique d'un point de vue expérience, en plus de posséder chacun leurs propres qualités et une compétence dominante. En fonction du besoin et de la stratégie de l'entreprise, il faudra de toute évidence étudier leur background technique.

Dans ce cas de figure, le CTO ne s'applique que pour les petites structures, comme les startups, car il est sensé posséder toutes les compétences. Il est donc plus économique d'avoir ce type de ressource, même chère, que d'avoir 2 ressources sans lead.

Concernant les grandes structures, comme le CTO ne développe plus, pour démarrer une application web from scratch, il suffit d'avoir un lead developer expérimenté. Ce dernier va pouvoir mettre en place toute la stack technique, initier les premières fonctionnalités, puis encadrer la future équipe.

La dette technique

Lorsqu'on démarre un projet, on ne parle jamais de la dette technique, soit par ignorance, soit volontairement pour la dissimuler.

Il existe 2 types de dette technique :

  1. la dette technique causée par un non respect des normes/standards et des erreurs de conception. Cela est due principalement par un manque d'expérience et une absence de contrôle sur la qualité du code. Cette dette est appelée dette technique non intentionnelle ;
  2. la dette technique intentionnelle permet la livraison dans les délais, mais doit sacrifier la qualité sur la conception pour gagner du temps. Cette pratique est courante. Cette dette technique peut s'accumuler, puis devenir impossible à rembourser, car il y aura toujours d'autres priorités.

Quelque soit le type de dette technique, la dette technique est inévitable, mais peut être réduite selon l'environnement technique, le niveau d'expérience des ressources et la méthodologie mise en place.

Le secret dans tout cela, c'est qu'il n'y aucun secret : la simplicité prime. Plus c'est simple, et moins il y aura de risque, et donc de dette technique. Pour cela, le CTO a un rôle important a jouer, et beaucoup sous-estiment son pouvoir sur l'équipe.

Après avoir simplifier les processus et faciliter le travail pour son équipe, le CTO émet naturellement une aura. Cette aura est ce qui donne le sentiment de sécurité et de confiance, et crée justement un climat de bienveillance. Donc aucune pression, ni stress, pour permettre à l'équipe de monter en compétence et de faire juste son travail.

Tout cela fait un peu ésotérique, mais comment appelez-vous le fait que parfois, vous êtes en total confiance et serein en présence de certaines personnes, et qu'avec d'autres, vous êtes mal à l'aise ?

La dette technique est quelque chose à prendre vraiment très au sérieux. Elle est dépendante étroitement de la qualité de tous les critères cités précédemment (connaissance, argent, temps, technologie, framework, méthodologie, équipe, CTO et lead developer). Elle va décidé de la réussite ou non du scale-up.

Conclusion

La technique est dépendante de la connaissance. La connaissance est détenue par l'humain. L'humain est une ressource. Il a un passé (expérience), un présent (besoins et attentes) et un futur (projet). Chaque ressource est unique, définie par son vécu, avec ses succès et ses échecs.

Comprenez que le choix technique ne se résume pas seulement à la technique. C'est aussi prendre en compte l'humain qui en détient la connaissance, et qui permet donc la concrétisation de tout projet.

Lorsque vous rencontrez la ressource tant convoitée, ce n'est pas qu'une personne qui sera face à vous, mais c'est toute sa vie et son expérience qui s'offrent à vous. A ce niveau d'éveil, la question n'est plus de savoir si vous avez trouvé la perle rare, mais si vous êtes à l'image de ses attentes (maintenant) et ferez partie de son avenir.

Après tout, le choix technique n'est peut être pas si important que ça, puisque l'humain prime. Cependant, si vous avez l'humain, vous aurez la connaissance, la méthodologie et la technique, en somme la technologie, et peut-être même l'avance technologique.

Ne retenez qu'une seule chose : les personnes qui réussissent n'ont jamais emprunté les même voies que les autres. Elles ont vécu beaucoup d'aventures, ont énormément d'expérience, et sont constamment en quête de savoir.

Donc pour bien démarrer une application web from scratch, trouver cette personne en qui vous pourrez y mettre toute votre confiance. Elle s'occupera de mettre en place l'environnement technique, une équipe, et la méthodologie. Dans cette configuration, si vous avez la « connaissance » (ressource), il vous faudra ensuite assurer d'avoir l'« argent » pour conserver cette ressource et gagner du temps. C'est le principe des 3 clés de réussite : la connaissance, l'argent et le temps.

La plus importante de ces 3 clés est de loin la connaissance, car sans elle, aucun projet ne pourrait se concrétiser. Ca sera donc votre point de départ… Trouvez cette ressource, puis tout coulera de source, comme l'eau qui trouvera toujours son chemin.