Quelle est la meilleure technologie pour mon application?

Quelques années avant, j’ai reçu une question semblable, lors d’un échange concernant la performance des langages de programmation et leur efficacité, afin d’implémenter un certain nombre de fonctionnalités. Or, et pour cette question en particulier : Quelle est la meilleure technologie pour mon application? Les choses ont rapidement avancé.

A ce jour, on commence à parler de la technologie à utiliser au lieu du langage de programmation. La simple et directe réponse sera : le choix de la technologie dépend de plusieurs facteurs. En effet, il dépasse le langage de programmation et la technologie elle même.

Dans cet article, je partage mon point de vue concernant les facteurs décisifs pour choisir la technologie adéquate pour un projet informatique.

1. Le projet

Oui, c’est la première question. Qu’est-ce que nous voulons exactement faire? Est-ce qu’il s’agit d’un site web? d’une application mobile? d’une ERP ou d’un système d’information? Est-ce qu’il s’agit d’un système embarqué ou d’une solution IoT? Chaque projet vient pour répondre à une problématique très précise dans une contexte précis. La définition du besoin et son analyse permettent de bien se situer par rapport à la question technologique.

Certaines problématiques peuvent être traitées en utilisant des langages scriptes. D’autres nécessitent des langages plus évoluées, alors que d’autres peuvent même faire coexister plusieurs familles de langages. Répondre au besoin d’un site vitrine ou blog ne se fait pas de la même manière pour créer un portail B2C ou B2B évolué. Gérer des machines connectées sur Internet ne fait pas appel à des langages dédiés à la réalisation des interfaces utilisateurs. Gérer les ressources d’une machine (CPU, mémoire) favorise l’utilisation d’un langage précis, même s’il existe un autre qui peut aboutir aux mêmes résultats. 

2. L’équipe de développement

En effet c’est un facteur très important. Il faut toujours commencer par auditer ce que vous avez comme moyens et ressources. Les ressources humaines sont les plus importantes, et leurs expériences cumulées constituent la connaissance collective de votre organisation. Si vous avez une équipe qui a capitalisé sur une technologie particulière, il vaut mieux de travailler avec cette technologie. Les milliers d’heures passées pour réaliser et livrer les projets précédents doivent se considérer comme un investissement à long terme que votre organisation a dû le faire pour monter en compétences leurs collaborateurs. Donc, la question que vous devez poser est la suivante : Quel le corps de compétences que nous avons dans notre organisation? Cette réponse vous amènera directement vers vos collaborateurs.

Il se peut que vous aurez besoin d’une autre compétence dans votre équipe, mais ceci ne veut pas dire forcément que vous devez changer votre domaine d’excellence. Il suffit de chercher cette compétence dans l’écosystème où vous avez réussi à bâtir une expérience.

Ceci est dû heureusement au fait que presque toutes les technologies apportent des outils de développement généraux pour répondre à la plupart des problématiques liées à la modélisation des solutions.

3. Corps Technologique (Langage inclus)

Une fois le corps de compétences de votre équipe projet est validé, vous devez valider que ces compétences sont suffisantes pour répondre aux exigences imposées par le nouveau besoin. A cette phase-ci vous serez face à deux situations :

1. Votre corps technologique est largement suffisant et satisfaisant. Dans ce cas, vous pouvez vous lancer directement dans les autres étapes comme vous le faites toujours . Pas vraiment, il y a des choses à vérifier avant de se lancer.
2. Le corps technologique n’est pas suffisant. Dans ce cas, vous seriez invités à le complémenter par une autre technologie regroupant l’ensemble des solutions dont vous avez besoin.

La première idée géniale qui vient par l’esprit est : Quelle est la technologie émergeante actuellement? Croyez moi, c’est la chose que vous ne devez pas absolument faire, surtout dans le cas des projets qui doivent créer de la valeur pour votre organisation et qui doivent passer en production. La plupart des chefs de projet techniques et même des architectes se lancent directement dans le benchmarking pour choisir un nouveau nom qu’on vient d’entendre. Ceci constitue un très grand risque non maîtrisable. En effet, une nouvelle technologie qui vient d’apparaître a besoin de faire preuve d’efficacité, si vous optez pour elle vous rendez service à l’éditeur sur le compte de votre projet. Or, que ceci peut être fait dans le cadre d’une activité de recherche et développement (que je vous conseille fortement de l’avoir dans votre organisation). 

4. Time to Production

Nous parlons souvent du time to market pour exprimer la durée nécessaire pour concevoir, développer un produit et le mettre sur marché. L’optimisation de cette durée pour une entreprise permet de devancer ses concurrents et augmenter sa rentabilité. Vu que chaque affaire maintenant est une affaire de logiciel, il faut prendre en considération le logiciel, l’application ou le système d’information entrant en jeu pour faire sortir le(s) produit(s) d’une organisation. D’où l’obligation de traiter le corps technologique en terme de rapidité (ou encore agilité) lors de l’implémentation des fonctionnalités souhaitées dans la solution finale. En pratique, ceci se traduit par la nécessité de vérifier la capacité de la technologie utilisée à apporter un livrable de valeur dans des délais réalistes, tout en permettant un bon positionnement de l’organisation par rapport à ses concurrents. Parmi les points à vérifier :

• Est-ce que la technologie accélère ou bien ralentit le processus de développement?
• Est-ce qu’elle est facile à utiliser dans toutes les phases de projet?
• Est-ce qu’elle nécessite une montée en compétences de l’équipe de projet?
• Est-ce qu’elle a fait preuve dans des projets similaires en se basant sur des cas d’étude publiés?

5. Agilité de l’écosystème

Comme je l’ai précisé plus haut, on ne parle plus du langage de programmation, c’est une affaire de technologie. Alors que cette dernière ne peut aboutir sans un écosystème lui permettant de donner lieu à des solutions (produits) avec un cycle de vie qui dépend du secteur d’activité de l’organisation. Dans chaque étape de ce cycle, un ensemble de techniques et de méthodes peuvent coexister. Autrement dit, pour chaque étape vous devez veiller à ce que votre équipe aie tout ce qu’il faut pour mener à bien sa mission. Parmi les questions que vous devez poser:

• Est-ce que la technologie nous permet de générer rapidement un premier prototype (PoC ou MVP)?
• Est-ce qu’elle nous permet d’implémenter les bonnes pratiques de conception et de sécurité?
• Est-ce qu’elle permet d’implémenter l’expérience utilisateur désirée?
• Est-ce qu’elle fourni une solution de tests unitaires à un coût minime?
• Est-ce qu’elle fourni des solutions d’interfaçage avec des applications tiers (Messagerie, Moteurs de processus, GED, agents de message, streaming…)?
• Est-ce qu’elle permet de fluidifier l’intégration ainsi que la livraison continues?

A ce propos, tous les éditeurs classiques (Oracle, Microsoft, Apache, Pivotal…) ont déjà pris ceci en considération dans leurs solutions, ce qui leurs donnent une position avancée par rapport aux startups émergeantes.

6. Support

Pratiquement, grande ERP ou simple application, les deux font partie du patrimoine de l’organisation qui doit être maintenu et entretenu. Pour ce faire, il est indispensable de prévoir un service de support. La technologie en elle même doit avoir un support technique permettant sa continuité. Ceci peut être traité sur deux niveaux :

• Niveau interne : concerne directement l’équipe projet en termes de leur efficacité à détourner les éventuels problèmes qu’ils peuvent rencontrer tout au long du projet. Chose qui dépend étroitement de la maturité et l’expérience des collaborateurs, ainsi que la mise à niveau de leurs compétences à l’aide des formations.
• Niveau externe : concerne l’éditeur de la solution, la qualité de la documentation fournie, et l’efficacité du support technique offert. Pour l’Open Source, on rajoute le dynamise de la communauté et sa “générosité” dans le partage et la gestion de ses connaissances.

A ce jour, l’Open Source gagne de plus en plus, donnant lieu à plusieurs projets. De nombreuses organisations gouvernementales l’ont considéré comme choix stratégique à cause de sa communauté et le support qu’il fournit. Sachant que la plupart des gens font toujours la confusion entre Open source et gratuité.

Ceci est dit car pour certains dirigeants, lorsqu’on vient à la question de support, ils optent pour les solutions payantes. Tout simplment, ils ignorent l’Open Source. Ils croient que, vu qu’elles sont payantes, l’éditeur va trouver immédiatement la solution. Croyez moi, j’ai été témoin à plusieurs reprises de la non efficacité de grands éditeurs. Vous connaissez certainement des histoires semblables.

7. Conclusion

Pour conclure, la prise de décision d’un choix technique ressemble à un acte de mariage (Je n’exagère pas). C’est une affaire très sérieuse qui peut impacter même la performance  de toute une organisation et son avenir. Par conséqent, et pour répondre à la question : Quelle est la meilleure technologie pour mon application? il faut prendre en consdération les points suivants :

• Définir exactement l’objet du projet et son contexte d’application
• Auditer et évaluer le corps de compétences de l’équipe projet
• Valider ou raffiner le corps de compétences de l’équipe projet
• Evaluer la technologie cible de point de vue Time To Production
• Evaluer l’agilité de l’écosystème de la technologie
• Evaluer la question de support de point de vue interne et externe par rapport l’organisation

_{Image Drazen Zigic sur Freepik}