Une application métier avec Drupal ?

Ce billet est une restranscription synthétique de la conférence Retour d'expérience : une application métier avec Drupal donnée au meetup Drupal Lyon le 7 avril 2016.

Drupal est particulièrement reconnu en tant que Gestionnaire de contenus (CMS) et plateforme de développement (CMF). Sa vocation principale est de propulser des sites Internet. Mais Drupal peut-il être utilisé comme support pour développer une application métier ?

En effet, si de nombreuses applications métier utilisent encore l'architecture classique du client / serveur avec un client lourd, celles se basant sur les technologies web n'en sont pas moins de plus en plus nombreuses, sans même parler de celles conçues sur un modèle Saas. Et bien souvent des sites Internet peuvent s'apparenter à des applications web tant les fonctionnalités offertes et les interactions avec les utilisateurs sont riches.

Quelles sont les avantages d'utiliser Drupal pour une application métier ? Quelles sont aussi ses limites ? Après une expérience récente en la matière, je vais essayer de dessiner quelques grandes lignes sur la pertinence, ou non, du choix de Drupal pour un tel type d'usage.

Les délais

Le seul besoin que nous connaissons avec certitude, et qui n'évoluera pas, est sa date de livraison. C'est possible pour demain ?

Des délais très contraints pour la réalisation d'une application web peuvent être un élément décisif pour le choix de Drupal. Par délais contraints, j'entends ici une date de livraison impérative, à courte échéance, quitte à ré-évaluer la couverture fonctionnelle de l'application. Drupal permet de mettre en oeuvre très rapidement des spécifications fonctionnelles, sans qu'elles doivent nécessairement être décrites dans le moindre détail, et de les livrer au fur et à mesure. Toute la phase de spécification technique détaillée peut alors être considérablement réduite, du fait entre autres de la structuration de la base de données de Drupal.

Des besoins évolutifs

Marcher sur l'eau et développer une application depuis des spécifications sont faciles. Si ces deux éléments sont gelés.

La conception d'une application avec Drupal permet de prendre en compte au cours du développement, et dans une certaine mesure, une modification des besoins ou encore la prise en compte de nouveaux besoins. A titre d'exemple, la modification d'une relation de type 1-1 en 1-n peut être réalisée très facilement sans remettre en cause tout le schéma et la modélisation des données (cf. La structure des données). Et la livraison très rapide des écrans de saisie, de modification ou de restitution permet à la maîtrise d'ouvrage à la fois de s'approprier l'application et faire des retours sur ses besoins qui ont pu être mal exprimés ou compris à l'origine.

La structure des données

Le schéma de la base de données de Drupal ferait hurler plus d'un architecte système soucieux d'une intégration de l'application dans le système d'information général, et attentif à une modélisation des données conforme aux standards. En effet à chaque champ ajouté à une entité correspond une table dans la base de données, ce qui peut générer des requêtes avec de nombreuses jointures pour récupérer l'intégralité d'un objet. Mais ce défaut de Drupal est à la fois une de ses forces. C'est Drupal qui génère son schéma de base de données au fur et à mesure de la conception de l'application, et c'est pourquoi la phase des spécifications détaillées, dans son aspect modélisation des données, peut être considérablement réduite. En outre, l'intégration de l'application Drupal dans le système d'information peut être facilitée par la mise en place de webservices assurant les flux de données avec des systèmes tiers et permettant de s'abstenir de maintenir des requêtes SQL complexes, spécifiques à Drupal.

De plus, si la modélisation des données et leurs transcriptions dans la base de données selon un schéma "classique" est réellement un impératif, il est toujours possible de créer ses propres entités dont la table correspondante peut contenir l'ensemble des propriétés y afférentes. Mais alors, ce qu'on peut gagner en lisibilité au niveau de la base de données nécessite du développement, et donc du temps, supplémentaire, et impose de concevoir le modèle des données attendues, et  donc des besoins bien définies, et définitifs, en amont de la conception.

La complexité de l'application

Tout devrait être rendu aussi simple que possible, mais pas plus

La complexité d'une application peut être évaluée selon plusieurs composantes : par le nombre de données et leurs relations entre elles, ou encore par le nombre d'acteurs devant interagir avec l'application selon des profils différents pour n'en citer que deux. Le choix de Drupal dans le premier cas doit être réalisée avec précaution. Les relations de type n-n peuvent bien sûr être adressées, mais la mise en place d'une ergonomie optimale pour ce type de saisie peut s'avérer coûteuse en temps. Les performances de l'application peuvent être également fortement impactées selon le nombre de relations "complexes" à mettre en oeuvre. En revanche, Drupal permet d'adresser en toute simplicité et efficacité la complexité d'une application liée à de nombreux acteurs et profils différents, et donc une gestion de droits très fine.

La gestion des droits

C'est ici un réel point fort de drupal. Etre capable de gérer de mutliples profils, disposant de droits différents, qui eux-même peuvent varier en fonction d'attributs affectés aux utilisateurs, et qui peuvent être modulés en fonction d'autres attributs liés aux objets eux-même. Pour ce type d'application web, dont le principal enjeu est de fluidifier les processus d'alimentation et de validation de données, effectués par de nombreux utilisateurs (500, 1000, 5000, etc.), Drupal est une solution qui peut s'avérer tout à fait pertinente. Avec la possibilité de connecter Drupal sur tout type d'annuaire d'entreprise (LDAP, CAS, etc.), automatiser l'affectation de droits d'accès différents selon certains attributs de l'utilisateur disponibles dans l'annuaire requiert un effort relativement modeste au vu des enjeux pour de telles applications, qui nécessitent une intégration forte dans le système d'authentification interne pour en faciliter son appropriation.

La tracabilité

Drupal permet nativement de mettre en oeuvre un suivi des modifications effectuées sur les données, et assure ainsi une tracabilité des données sans aucun effort à priori. Cela reste toutefois à nuancer par le fait que pour disposer de cette tracabilité par défaut, il faut utiliser les entités de base fournies par Drupal, les noeuds. Et donc si l'application web prévoit la création d'entités spécifiques, il faudra gérer spécifiquement la tracabilité pour ces entités, ce qui peut générer un travail supplémentaire conséquent. En outre, l'utilisation des révisions de Drupal peut générer des bugs en fonction des modules utilisés, selon qu'ils soient bien intégrés, ou pas, avec le système de révision natif à Drupal. Une analyse plus détaillée mérite d'être réalisée pour évaluer la pertinence de Drupal selon ce critère.

Les processus de validation

Si l'application métier nécessite de nombreux processus distincts d'alimentation et de validation de données, ceci peut être adressé de nombreuses manières par Drupal. Nous avons presque l'embarras du choix, que ce soit avec des modules prêts à l'emploi, ou encore avec l'utilisation du framework Rules. Drupal est une solution tout à fait mature concernant ce type de fonctionnalités, au même titre d'ailleurs que les notifications.

Les notifications

Dans le cas de processus de gestion de données répartis sur une chaîne d'acteurs conséquente, la mise en place de notifications peut être un pré-requis pour faciliter l'usage de l'application. Etre prévenu de qui à fait quoi selon un certain nombre de critères, ou encore être notifié qu'une action est attendue de notre part. Le framework Rules nous permet de gérer en quelques clics, ou presque, ces cas d'usage. Pour des notifications plus complexes, par exemple un journal d'activité, avec des notifications au choix immédiate, journalière ou hebdomadaire, la suite Message permet de répondre à ce besoin de façon robuste, et permet aux utilisateurs de ne pas être submergés de notifications, leur laissant le choix, selon leurs critères, de la périodicité des notifications. 

Les restitutions et exploitations

Les restitutions et exploitations de l'application web sont un des points les plus cruciaux, outre les délais et la compléxité de l'application, dans la pertinence du choix de drupal. Autant mettre en place des restitutions synthètiques ou détaillées à 2 dimensions, de façon visuelle au moyen de librairies graphiques, ou de façon analytique par la génération de tableaux de données, peut être réalisé plutôt facilement avec Views et ses nombreuses contributions, autant une exploitation multidimensionnelle des données peut commencer à être compliquée à implémenter. Tout dépend si l'application doit embarquer absolument ce type d'exploitations complexes, ou s'il est possbile de les externaliser dans une certaine mesure, avec par exemple la connexion d'outils d'analyse spécialisés sur la base de données de Drupal. Ce point doit être étudié avec vigilance, car c'est un poste de développement qui peut très vite devenir très chronophage, et pondérer alors l'intérêt du choix de Drupal vis à vis de ses autres forces.

En guise de conclusion

Reconnu en tant que CMS, Drupal permet aussi de réaliser bien plus qu'un site Internet. Il peut permettre de réaliser des applications web métier à moindre coût, dans des délais extrêmement contraints. C'est une solution qui offre une souplesse sans égale pour s'adapter aisément à des évolutions fonctionnelles, et accompagner les processus métier tout au long de leur cycle de vie et de leurs besoins.

Et ce grâce à l'architecture atomique de son schéma de base de données, quitte à faire hurler quelques architectes et urbanistes du système d"information.

Selon la complexité des données à traiter, leurs fréquence, le nombre d'acteurs dans les processus, les restitutions et exploitations envisagées, Drupal peut être une solution avantageuse à plus d'un titre : sur les délais de réalisation, sur le budget global du projet, et sur le coût total de possession. Parce qu'une partie non négligeable du développement aura déjà été faite. Tout simplement.

En revanche, si l'application nécessite de nombreux développement spécifiques (création de nombreuses entités sur mesure, etc.), que ce soit pour satisfaire des besoins métier complexes ou la compréhension d'un administrateur de base de données, une analyse plus détaillée méritera d'être conduite : le choix d'un framework moins technocentrée (Symfony2, Java, etc.), avec une méthodologie rassurante (étude amont, spécifications fonctionnelles, spécifications techniques détaillées, conception, etc.) pourra s'avérer être le meilleur choix.

Le meilleur couteau suisse ne peut pas être une somme exacte des meilleurs outils disponibles pris séparément. C'est au final une question de compromis. Et une application métier web, ce n'est finalement qu'un site Internet avec un peu plus d'interactions avec ses utilisateurs, non ?