Coolforest.net

Cela fait quelques années que mes patrons successifs sont à la recherche d'une solution logicielle de système d'information dit "générique", qui couvre les besoins de la plupart de leurs clients. Ue solution "sur l'étagère", prête à installer, rapide à "configurer", se présentant comme un gestionnaire de sites internets dit "institutionnels", avec frontoffice et backoffice.

La plupart des collègues avec qui j'en ai discuté (récemment encore) partagent avec moi des réflexions un peu sceptiques. Ces solutions "miracles" de gestion de contenu connaissent actuellement leur avènement avec les différents systèmes de gestion de contenu (CMS) proposés "out of the box" et censés couvrir 90% des besoins des clients utilisateurs. Pour le web, il s'agit de Typo3, Joomla!, eZ Publish ou Zope/Plone, pour les plus connus.

Dans la réalité, on a très souvent vu les développeurs s'arracher les poils de la barbe pour faire faire à ces CMS ce que le chef de projet avaient finalement réussi à définir dans l'analyse du besoin (souvent touffu) du client. Les fonctionnalités spécifiques deviennent urgentes, on se rend compte que ledit CMS générique ne les contenait finalement pas. Elles nécessitent alors des développements supplémentaires, difficiles à chiffrer et forcément coûteux ^[1] parce qu'ils sont identifiés trop souvent après le début de la réalisation, ou parce qu'ils prennent la forme de maintenances évolutives sans grande cohérence avec l'existant. C'est à ce moment que les sirènes de nouvelles solutions génériques, plus à jour, toujours plus complètes en fonctionnalités, se font alors entendre, autant du côté de la MOA que de la MOE.

La comparaison entre solutions génériques dites "miracles" et solutions spécifiques pragmatiques s'apparente souvent au débat classique entre "l'artisanat" d'une part et "l'industrialisation" ^[2] d'autre part. Ce débat revient souvent dans la presse en ligne ^{[3] [4]}. Je réunis ici quelques arguments pour et contre le fait d'investir dans le développement d'une solution générique. Mon approche est celle de l'architecte ou du développeur, bref, de celui qui au final devra mettre les mains dans le cambouis... et observer la réaction du client lors de la livraison du produit.

Solution générique ("packagée"), les arguments "pour" :

Développer une solution générique à vendre à la majorité de vos clients permettrait :

• de vendre plus à moindre coût ;
• de ne "pas réinventer la roue" ;
• d'éviter les développements spécifiques, "mal testés", "instables", "sclérosants" ^[5] ;
• de permettre une bonne maintenance du progiciel ;
• de maitriser l'évolution du produit sous forme de versions ;
• d'endiguer la créativité débordante (et ingérable) des architectes ou des développeurs ;
• de s'appuyer sur des développements stables, testés, documentés ;
• de proposer un produit abouti, que l'on voudrait présenter bientôt comme une "référence du marché" ;
• un bon pilotage de projet ne devrait pas dépasser 10% de développements spécifiques ^[6] ;
• l'absence de développements spécifiques est un gage de sérieux ^[7].

Les arguments "contre" :

• ça ne répond jamais à tous les besoins du client, qui est demandeur de fonctionnalités toujours plus spécifiques, fonctionnalités qui au final reviennent souvent à remettre en cause l'architecture et le fonctionnement global d'une solution "générique" ^[8] ;
• c'est une utopie : les seules solutions génériques qui "durent" et qui "marchent" sont soient réservés à des niches très réduites, soient bénéficient d'un monopole de fait, soient sont des OS propriétaires ou de très gros progiciels.
• la maintenance des solutions génériques pose autant de problèmes que pour une solution spécifique (demandez aux utilisateurs de Zope/Plone ce qu'ils en pensent).
• dès qu'une solution packagée est prête à être vendue, elle est déjà obsolète ;
• l'évolution des usages d'Internet (Web 2.0 et compagnie) est telle que l'usage d'une solution "out of the box" ne permet pas de suivre rapidement les innovations actuelles auxquelles l'application web existante doit se conformer ;
• dans le domaine des applications métiers, que recouvrent de plus en plus les sites web dits "institutionnels", les clients sont tous différents et ils ont tous des besoins spécifiques et de plus en plus évolutifs ;
• le plus important, en général, ce n'est pas le logiciel, mais les données qu'il manipule. Et il vaut certainement mieux qu'un logiciel s'adapte aux données plutôt que ce soit l'inverse ;
• le mythe du type qui réinvente la roue est une chimère. D'une part l'existence des moteurs de recherche et des nombreux sites spécialisés (pour s'informer de l'état de l'art dans à peu près n'importe quel domaine) permet à chacun de se constituer avec le temps une bonne culture de ce qui existe déjà. D'autre part, l'abandon de la programmation purement procédurale et l'avènement de la programmation orientée objet depuis plus de 10 ans maintenant permet à chaque équipe de développement de maintenir pour elle-même ses propres bibliothèques logicielles, sans cesse ré-utilisées et améliorées ;
• la progicialisation systématique des logiciels va à l'encontre de ce qui fait l'intérêt et la motivation des concepteurs et développeurs, dont le travail est à 100% une oeuvre de l'esprit. En conséquence, l'industrialisation à tout crin du développement logiciel est souvent mal vécue par les équipes de production, elle freine la créativité, le plaisir, l'inventivité et au final l'innovation.

Les solutions forcément "packagée"

Elles ne s'imposent que dans certains domaines comme les progiciels de gestion intégrés (PGI), les ERP, les logiciels de comptabilité, des domaines ou les fonctionnalités sont très formelles et très liés au domaine juridique, bref qui imposent un gros suivi fonctionnel, que l'on a intérêt à mutualiser, et qui se présente donc assez logiquement sous la forme de progiciels. ^[9]. Ces solutions packagées risquent en revanche de devenir inconsistantes quand il s'agit de gérer le métier même d'une entreprise, dont l'activité est toujours particulière, et notamment quand ce type de système d'information doit prendre la forme d'une application web ^{[10] [11]}.

Ce qui me plait (et qui marche mieux) :

Le débat générique / spécifique montre rapidement les limites de ces deux aprochent. Chacun défend ses intérêts et sa méthode. La formule qui me semblerait optimale, celle qui pourrait satisfaire tout le monde (les développeurs/intégrateurs, les commerciaux et leurs clients), c'est une solution construite en "briques" qui sont à la fois indépendantes et interopérables, une solution pensée un peu comme une cuisine aménagée ou bien une maison dont les éléments sont des "options" modulables (cf. les maisons sont vendues par les promoteurs sur catalogue). Cela peut se comparer aussi aux PC "à la carte" vendus par DELL.

Les point communs de ces comparaisons, c'est un système souple, conçu autant pour celui qui va l'utiliser que celui qui va devoir le le construire au départ et le faire évoluer ensuite. Dans cette solution, les "modules" ou "briques" sont compatibles entre eux, comme des pièces de Lego, parce qu'ils sont bâtis sur un même socle, idéalement bien documenté, et sur des conventions communes. Cela forme un éco-système où chaque module est ré-utilisable en tant que tel et est "interopérable" avec les autres modules, présents et à venir. Du point de vue de la conception logicielle et du développement, cette solution s'apparente en plusieurs points à la programmation orientée composant.

A ma connaissance, très très peu de solutions génériques offrent ces caractéristiques : Plusieurs moteurs de CMS ou de blogs proposent des extensions, mais ils proposent quasiment jamais un vrai socle de développement bien documenté et un environnement profondément évolutif. eZ Publish est l'un des rares à proposer à la fois un CMS, un socle commun (eZ Components, bibliothèques de composants) et des "extensions". Tout cela prend la forme d'un éco-système plutôt riche cohérent. Les extensions d'eZ et la documentation rendent facilement extensible le CMS proposé "out of the box". eZ Publish et eZ Components sont distribués en licence GNU/GPL.