← Retour

Comment choisir une technologie pour un projet ?

~5 min

Comment choisir le bon framework ? Comment choisir le bon langage de programmation ? La bonne méthodologie ? La bonne architecture ? (Wow c'est pas simple)

Sage sont les personnes qui se posent ce genre de question avant de démarrer un projet.

Surtout si l’entreprise a un “process qui roule”, il faut à tout prix éviter de tomber dans la loi de l’instrument, on choisit un outil pour un travail, on ne tord pas le travail pour se servir de son outil favori, plus d’infos ici.

Avant de choisir fermement une technologie sur un projet il faut vérifier quelques points. On évite beaucoup de mauvaises surprises en cours de développement. Cette liste est aussi valable pour le choix d’une bibliothèque, d’un logiciel, etc.

Schéma avec beaucoup de conséquences et influences d'un choix technologiqueVoilà tout ce qui peut faire foirer un projet

Les points clés

🛠 Maintenabilité

  • L’équipe connait-elle bien la technologie ?
  • Est-ce que la technologie est suffisamment bien documentée sur le long terme afin d’assurer la maintenance ?

🔥 Capacité de mise à l’échelle

(scalabilité en franglais)

  • Comment s’opère la montée en charge de la technologie ? Il faut consulter les benchmarks et en effectuer soi-même. Réaliser des matrices d’acceptation sur un matériel équivalent à celui utilisé en production.
  • Est-ce que la technologie est payante ? Gratuite puis payante ? Est-ce limitant pour la suite du projet ? Quel est son modèle économique ? Qui est derrière ?
  • Si la technologie est d’apparence cher mais qu’elle économise le boulot d’une personne, est-ce que cela vaut le coup ?

🤩 Popularité

  • Plus une technologie est connue et reconnue plus on obtiendra un support rapidement.
  • Vous aurez plus de chance de trouver des développeurs qualifiés et de l’aide sur le net.

👗 Adéquation par rapport au projet

  • Un langage bas niveau ne sera pas forcément plus performant, tout comme un langage haut niveau pourra tout à fait convenir meme sur un gros projet si celui ci est bien utilisé.
  • A t-on le temps d’utiliser une technologie complexe ?
  • Un framework e-commerce est-il adapté pour un blog ?
  • Un langage web non typé est-il adapté pour un projet critique nécessitant de la performance et une robustesse du code ?
  • Compatibilité avec les plateformes voulues

Il n’y a rien de plus durable qu’une solution temporaire.

Exemple : Pour une technologie mobile il faut prendre en compte la consommation de batterie / réseau etc.), nombre de dépendances / pré requis (afin de limiter le poids sur l’appareil, mais aussi assurer sa stabilité)

👴 Maturité de la techno

  • Une technologie à beau être populaire, si elle est complètement immature pour un projet en production serieux, alors elle ne permet pas un développement serein.
  • La maturité passe par vérifier le nombre de mise à jour par mois, la taille de ces mise à jour et leur impacts sur le code en production.
  • Le nombre d’API différentes, est-ce qu’elles couvrent les usages que vous avez besoin ? (Exemple, nouveau framework super cool, mais impossible de réaliser nativement de simple requete HTTP ou une connexion à une base de donnée ! Pas de bonnes pratiques ni convention ! etc.)
  • Etudiez bien les petits détails tout bête que l’on ne peut voir qu’en testant la solution.

Exemple : Au début de l’histoire de Swift chaque mise à jour du langage cassait totalement le code effectué avec la version précédente sortie a peine 6 mois avant. Imaginez devoir re-développer tout les 6 mois vos applications en productions parce qu’elles ne fonctionneront plus au prochain build ! Un enfer ! Et c’est ce qui est arrivé pendant 4 à 5 ans avec Swift, de quoi rendre fou les développeurs.

Donc technologie attirante et populaire ne signifie pas qu’il faut se jetter dessus.

🔐 Sécurité

  • Le niveau de sécurité attendu, trop de sécurité peu nuire au projet. Si le projet ne voit jamais le jour car vous mettez trop de préssion sur les développeurs alors vous n’aurez certes pas de problème de sécurité, mais vous n’aurez pas de projet non plus.
  • Votre choix doit se porter sur une technologie ou un framework qui vous facilite la vie en vous proposant des outils de sécurité pré-existant et facilement manipulable. Exemple : Laravel et sa suite d’outil, comme Fortify, Breeze, Sanctum et Socialite qui facilitent votre vie de développeur.
  • Attention à ne pas trop embetez l’utilisateur final avec des consignes de sécurité sur-réfléchis (pensez au principe KISS). La sécurité c’est comme tout, il faut savoir garder un équilibre, et éviter de trop penser aux cas d’école qui vont arrivé dans 0,001% du temps.
  • Le principal est de bien séparer les données personnelles de votre  flux de production classique pour brouiller les pistes un minimum (base de données séparée, stockage chez un tiers de confiance spécialisées etc.).

Une fois sélectionné un panel de solutions technique, vous pouvez effectuer une selection par critères plus adapté à votre situation.

TESTER T.E.S.T.E.R

J’insiste : TESTER

Ouais non mais : TESTER On ne peut pas dire qu’une technologie ou qu’une méthode ne convient pas sans l’avoir tester. Et comme on peut pas TOUT tester au moment d’un projet, c’est la qu’entre en jeu la veille active et les *side projects *(projets hobbies), la veille et l’experimentation personnelle c’est là que vous pouvez prendre des risques (et pendant les formations aussi alors profitez en).

“Tester c’est douter”. En fait c’est cool de douter, ça permet de chercher, creuser jusqu’à trouver la solution différenciante par rapport à ceux qui n’ont fait qu’égratigner la surface par peur de sortir de leur zone de confort.

Le contexte est roi 👑

Quelle est la valeur que l’on veut apporter à l’utilisateur ?

  • Si on apporte de la rapidité d’execution alors on sera moins regardant sur le nombre de fonctionnalités, on voudra des technologies qui nous mache le travail pour proposer un produit rapidement sur le marché pour optimiser l’UX avec les retours des utilisateurs.

  • A l’inverse si on vends de l’exhaustivité / un niveau de fonctionnalité professionnel, il faudra savoir guider l’utilisateur, utiliser des technologies évolutives et robustes sur le long terme quitte à consommer plus de temps pour tester plusieurs solutions en phase de faisabilité.

Conclusion

Ce petit mémo n’est pas exhaustif, savoir choisir une technologie requiert de l’expérience et une grosse culture générale.

Cela vous apporte les principes de base.