Choisir la bonne technologie web de développement

Une technologie web se compose traditionnellement de trois couches : le système de gestion de bases de données (SGBD) , le langage de développement et les outils éventuels de développement (API, Framework, solution logicielle) associés.

Quel système de gestion de base de donnée choisir ?

Le choix du système de gestion de bases de données pourrait faire l’objet d’un dossier à part entière. Base de données relationnelle ou de type noSQL, open source ou sous licence, ce ne sont pas les options qui manquent. Parfois, le choix s’effectue par défaut, parce qu’une autre brique fonctionne particulièrement bien avec celui-ci ou bien parce que l’on souhaite s’inscrire dans la continuité d’un choix d’éditeur (SQL Server et .NET).

Une grande majorité de projets web s’appuient sur une base de données MySQL.

Plus couramment, l’alternative se situe entre une solution sous licence (Oracle, SQL Serveur, DB2) généralement imposée par la DSI pour des raisons de cohérence et de compétences, et une solution OpenSource de type relationnelle (MySQL, MariaDB, PostgreSQL) ou noSQL (Cassandra, MongoDB).

La popularité des systèmes de gestion de bases de données

DB-Engine.com propose un classement par popularité des systèmes de gestion de bases de données. Ce classement s’applique à l’ensemble des projets informatiques et non pas uniquement les projets web.

Oracle, MySQL et SQL Server mènent toujours la danse, loin devant les autres solutions, y compris des solutions réputées comme PostgreSQL ou MongoDB. Et même si la plupart d'entre-elles "stagnent" ou bénéficient d'une croissance faible, on peut distinguer, depuis plusieurs années maintenant, une montée en puissance de MariaDB, qui même si elle n'est pas au même niveau que ses concurrents, continue à croitre de manière significative.

Définir le langage de développement le plus adapté

Pour les projets Web, trois langages de développement tiennent l’essentiel du marché : PHP, Java et .NET.

D’autres langages, comme Python ou Ruby peuvent se révéler intéressants. .NET est un choix qui s’inscrit dans une démarche d’éditeur. Pour PHP ou Java, il s’agira d’un choix d’école. Historiquement, Java était un choix d’informaticiens pendant que PHP était plutôt un choix d’agence. Aujourd’hui cette dualité s’est résorbée.

En pratique, on peut citer trois critères de choix du langage de développement. Le premier est l’expérience de l’entreprise ou du prestataire pour un ou plusieurs langages. Il n’est pas conseillé de se lancer avec un langage avec lequel on a peu ou pas d’expérience. Le second est l’environnement technique du projet. L’infrastructure envisagée, l’intégration dans un système d’information existant, ou encore la sécurisation de l’application, sont des facteurs qui peuvent conduire à un choix plutôt qu’un autre.

A moins de contraintes de DSI, le choix est conditionné par l’expérience et la solution logicielle choisie.

Ces facteurs sont normalement prédéterminés sous la forme de contraintes dans le cahier des charges de l’application. Enfin, une solution logicielle, comme un outil de gestion de contenu (CMS), peut avoir été pressentie ou même choisie pour des raisons d’orientation fonctionnelle ou d’exploitation. Cette solution conditionnera le choix du langage de développement. Par exemple, Drupal ou Typo3 s’appuient sur PHP, Alfresco ou OpenCMS exploitent Java, pendant que Sharepoint ou DotNetNuke s’associent aux solutions Microsoft.

De fait, pour un projet dont les contraintes sont avant tout fonctionnelles, c’est le choix de la solution logicielle qui prévaut. Vous pouvez choisir une solution de type packagée comme Prestashop (ecommerce) ou Odoo (CRM/ERP) ou encore DataShare (groupware). Vous pouvez également adopter une brique modulaire et adaptable comme un CMS (Drupal, DNN, Django CMS) ou un système ecommerce (Magento) ou une GED (Alfresco). Enfin, pour disposer de la plus grande liberté de mouvement, éventuellement en association avec une brique modulaire, vous vous appuierez sur un framework de développement (voir notre encadré sur le sujet) comme Symfony ou JWT.

Les objectifs du projet sont prioritaires, même si cela implique des choix techniques difficiles.

Au delà du choix du langage, il faut par ailleurs prendre en compte la "branche", c'est-à-dire la version qui sera utilisée dans le choix de la solution que vous mettrez en place. En effet, chaque branche n'est pas éternelle, suit un cycle de vie où elle sera maintenue par la communauté. Ce cycle de vie dépend du langage de développement que vous utilisez.  Pour reprendre l'exemple du langage PHP, elle est de 2 ans pour les bugs et les mises à jours de sécurité puis 1 an pour les bugs "critiques" de sécurité. Au-delà, la branche  n'est plus maintenue.

Vous l'avez compris, il est donc nécessaire de  partir sur un socle le plus "uptodate" possible afin de vous éviter des désagréments sur le long terme.

La liste des Frameworks de développement

Les langages de développement posent des modèles d’architecture, des méthodes de développement et une sémantique. Mais pour développer des applications, en particulier des applications web, même si le langage intègre de nombreuses possibilités – notamment PHP – il convient de lui adjoindre des capacités spécialisées. C’est l’objet même des frameworks. En voici quelques-uns populaires pour le développement d’applications web.

Prendre en compte les outils de développement

Nous l’avons vu, nombre de facteurs sont pris en compte à l’heure du choix. C’est pourquoi le risque existe de perdre l’objectif de vue : la réussite du projet. Certes les considérations techniques de maintenabilité, de sécurité ou de facilité d’intégration dans le SI, sont d’une grande importance. Mais si pour cela on doit renoncer à répondre à des besoins stratégiques du projet, alors on n’a pas la bonne réponse. Ainsi, les contraintes techniques d’un cahier des charges se doivent d’être compatibles avec les objectifs du projet, quitte à quelques compromis techniques. Par exemple, même si tout le SI d’une entreprise s’appuie sur des technologies Microsoft, il n’est pas interdit d’envisager PHP pour une application web périphérique dans la mesure où son exploitation est garantie et que les interfaces utiles sont prévues.