Cette étape peut être réalisée suite à la première itération de la définition du besoin. En pratique, un développeur s’oriente vers les technologies qu’il connaît et maîtrise. Ce n’est pas une mauvaise chose mais cela peut amener à tordre une technologie pour correspondre au besoin alors qu’une technologie plus adaptée pouvait être utilisée.
Regardons les technologies actuelles. Elles répondent à différentes problématiques. Une application ce sont des données en entrée, des traitements et des données en sortie. Une technologie doit permettre de réaliser traitements et réponses de façon optimale suivant les contraintes des utilisateurs.
Lorsque vous utilisez une application, vous manipulez des données. La question sur la provenance des données se pose. Où sont-elles stockées ? localement ? à distance ? les deux ? Stocker les données sur votre smartphone ou ordinateur permet un accès plus rapide. En contrepartie, elles prennent de la place et l’espace de stockage est limité.
Aucune application de musique et de vidéo (Youtube, Netflix, Deezer, …) ne pourrait fonctionner ainsi. C’est pour cela que les données sont récupérées sur un serveur distant. Ces applications permettent cependant de stocker localement un certain nombre de contenus dans le cas où vous n’avez pas accès au réseau.
Pour les traitements aussi, la question du lieu d’exécution se pose. Dans le cas d’un traitement complexe, il vaut mieux demander à un serveur spécialisé de réaliser le traitement que de le faire localement. Cela se révèle plus rapide. Cependant, l’application est inutile si vous n’avez pas accès au réseau.
Une autre question du traitement est de savoir s’il est optimisé à la plateforme ou universel. Concrètement, si votre application doit être utilisable sur un iPhone, un Android et un ordinateur, vous pouvez écrire et compiler 3 fois votre application. Niveau maintenance, c’est compliqué. Niveau performance, c’est le plus efficace.
Vous pouvez aussi passer par une machine virtuelle. C’est moins performant mais vous n’écrirez l’application qu’une seule fois. La 3ème option, l’interprétation, consiste à déléguer l’exécution. Le traitement sera interprété à la demande. En terme de performance, à moins que la plateforme n’implémente un compilateur JIT, c’est le plus lent. Devant la puissance des ordinateurs actuels, c’est imperceptible pour l’utilisateur final.
Je ne peux vous décrire en un article toutes les technologies disponibles. Il existe de nombreuses formations pour cela. Mais si je regarde mes contraintes (utilisateurs multiples, sécurité des données, intégration de services externes, …), je partirai sur des technologies web. L’application sera disponible sur un serveur et les utilisateurs se connecteront dessus.
Questionnaires et parties jouées seront enregistrées sur une base de données distante. Les résultats seront stockés sur le serveur et sur les smartphones des joueurs. Les technologies seront donc :
- PHP pour la partie traitement côté serveur (en pratique j’utiliserai le framework Symfony pour ne pas réécrire les problématiques déjà codées par d’autres développeurs)
- SQLite pour le stockage des données.
- Nginx pour la communication avec le client.
- HTML5 et CSS 3.0 pour les interfaces visibles par les utilisateurs.
- JQuery pour les traitements côté client.
Avec ce mélange de technologie ‘clientes’ et ‘serveurs’, je couvre l’ensemble des problématiques exprimés par mon application. Il existe bien d’autres technologies. L’exécution côté serveur aurait pu être écrite avec un framework javascript (node.js, …) ou avec des technologies propriétaires (Oracle, Microsoft, Progress, …)
Il en va de même pour chaque autre problématique. Je préfère rester sur les technologies les plus utilisées et les mieux documentées. Vous trouverez facilement sur Internet de nombreux tutoriels.