Dans un contexte où tout va très vite, beaucoup de gens, équipes et compagnies tentent d'aller le plus loin le plus rapidement possible afin d'être les premiers à proposer de nouveaux produits, services et fonctionnalités. Cependant, cette vitesse amène une certaine précipitation qui peut causer du trouble à vos projets, pouvant provoquer le redéveloppement de certaines fonctionnalités entières, des retards sur les planifications ou une instabilité en production.

Entre ce que j'ai pu vivre et tout ce que j'ai pu entendre de personnes en IT, j'ai pu constater que ça arrivait souvent, voir trop souvent. Après ça ne veut pas dire que les personnes/équipes/compagnies ont fait échouer leur projet. Une bonne partie d'entre eux ont réussi a ramener les projets dans la bonne direction et continuent à être utilisés.

Mais de là, différentes questions se posent :

• A quel prix ont-ils réussi à faire cela ?
• Combien de temps leur a-t-il fallu ?
• Est-ce qu'ils ont réussi à conserver la confiance de leurs clients?

En effet, sans parler de l'impact financier direct vis à vis du temps à redévelopper/stabiliser la solution, cela peut aussi avoir un impact financier indirect car des services qui ne fonctionnent pas correctement peuvent influencer la confiance de vos clients envers votre produit. Peut-être qu'ils ne vont pas arrêter d'utiliser directement vos produits, mais peut être qu'ils vont se tourner ailleurs si ils trouvent d'autres alternatives.
(Bien sûr ça n'est pas mesurable facilement, et ça dépend de la criticité des services.)

Et c'est pour cela qu'on va parler de quelques questions qui vous permettront de vous assurer que vous partez dans la bonne direction avec votre projet.

Quels sont les prérequis de mon produit ?

Penser en premier à l'expérience client, puis revenir à la technologie
Citation Steve Jobs

Cette question doit être posée dans le sens où on veut penser au produit final que l'on veut offrir au client. Quelles sont les fonctionnalités? Quels critères ses fonctionnalités doivent suivre? (durée de traitement, sécurité, certifications, volumétrie...)

En effet avoir une idée précise de ce que l'on veut à la fin est important car c'est le point crucial qui fait que beaucoup de projets sont refaits. Et ça arrive partout, ça m'est aussi arrivé par le passé. J'ai eu l'occasion de voir des projets réécrit partiellement ou entièrement à cause ça. Par exemple, arriver après 1 an de dev pour dire "au fait ces traitements doivent être fait en moins d'une seconde" alors que vous n'aviez aucune contrainte jusque là.

Si jamais votre projet est très vaste et qu'il contient beaucoup de fonctionnalités, focalisez-vous en priorité sur les fonctionnalités les plus contraignantes et/ou celles qui ont des besoins particuliers. En effet si au milieu de votre projet complexe vous avez des fonctionnalités qui font des CRUD d'une table de votre base de données et que vous n'avez pas de contraintes de temps de réponse, elles peuvent clairement être mises de côté car il y a de grandes chances qu'elles rentrent dans la stack technologique que vous allez définir pour vos autres fonctionnalités.

Dans quel contexte allez-vous créer ce produit ?

Ici on veut se demander quel type d'architecture on va utiliser, quels outils et technologies on va utiliser...

Par exemple :

• Faire des microservices pour une petite application pour lister les todos en local, ça n'est pas intéressant et c'est même overkill.
• Avoir un système incluant des boutiques, sites de paiement... dans un monolithe alors que vous savez que vous allez devoir gérer plusieurs boutiques sur le long terme et qu'elles vont partager des fonctionnalités, pas adapté

Aussi il faut voir vis à vis du contexte de l'entreprise. Si tous les développeur connaissent java, ça n'est pas forcément utile d'aller chercher un autre langage si les performances de Java sont suffisantes pour les besoins...

MAIS il faut vérifier que ça correspond avec les besoins technologiques de votre projet. En effet il peut être plus simple que tous les projets d'une même compagnie soit avec la même stack technologique. Ca simplifie les choses et ça permet d'être sûr d'avoir des personnes qualifiées qui peuvent aider/contribuer. Sauf que certaines technologies (langage front, backend, type de base de données...) ne vont pas correspondre à vos besoins. Dans ce cas, le risque est que vous ne le voyez que trop tard car personne ne s'est posé la question avant.

Quelle est notre vision du produit sur le long terme ?

Cette question est très importante car elle peut permettre de préparer le terrain pour le futur. L'idée n'est pas d'analyser directement le futur, mais de récupérer les informations que l'on peut et voir l'impact que ça peut avoir sur le service tel qu'on le conçoit actuellement.

Par exemple :

• Est-ce que certaines fonctionnalités vont être réutilisées? Si oui lesquelles? Comment seront-elles partagées? (librairie, microservice...)
• Est-ce qu'on vise sur le long terme une grosse augmentation au niveau de l'utilisation du service ?
• Est-ce que certains critères (comme la latence) risquent d'être plus strictes dans le futur?

Est-ce qu'on part dans la bonne direction ?

Question simple mais qui, vis à vis des points précédents, vont vous permettre de vous rechallenger sur votre projet et de valider que vous prenez la bonne voie.

Plusieurs solutions s'offrent à vous :

• consulter des experts dans le domaine (qu'ils soient dans votre compagnie ou non) afin de savoir si ce que vous voulez faire est faisable
• faire des POC ciblées sur vos points d'interrogation

Ces solutions sont un petit investissement en coût et en temps, mais ils peuvent être cruciaux pour vous conforter sur la direction à prendre.

---

Au final, on a pu voir qu'il n'y a pas de recette miracle pour trouver de quoi on a besoin ou non comme technologies pour un projet. Par contre, on a pu voir qu'avant de partir trop loin dans le développement, il faut :

• Prendre un peu de temps en amont pour comprendre quels sont les prérequis indispensables du produit
• Analyser le contexte de votre produit, ainsi que celui de votre entreprise
• Réfléchir au long terme
• S'assurer qu'on part dans la bonne direction

---

J'espère que ça vous aidera et si jamais vous avez des questions, quelles qu'elles soient (Il n'y a jamais de questions bêtes!) ou des points qui ne sont pas clairs pour vous, n'hésitez pas à laisser un message dans les commentaires ou à me joindre directement sur LinkedIn (même pour parler d'autres sujets!).