Component Based Development, Software reuse, Boîte à outils … et aujourd’hui framework … c’est toujours la même histoire. Celle de la réutilisation dans les développements informatiques. Malheureusement, force est de constater que l’on connaît peu de succès dans ce domaine au sein des entreprises et administrations.
Alors, le concept de framework est-il le nouveau « supplice de Tentale » pour les développeurs et chefs de projet ? Pas si sûr …
Chaque jour, sous nos yeux, la puissance de la réutilisation logicielle est démontrée. En effet, la révolution Open Source a fait de cette démarche et du travail collaboratif un art pour faire émerger les leaders que l’on connaît (Linux, Bind, SendMail, Apache, PHP, MySQL …). La notion de framework et de réutilisation de briques de base est une préoccupation constante chez les développeurs Open Source. Dans le domaine de la gestion de contenu Web, le projet Ion CMS en est un très bon exemple. Les contributeurs assemblent des briques Java libres telles que Castor, Lucene, Xalan, OSWorkflow … afin de fournir une solution de gestion de contenu opérationnelle. Cette solution bénéficiera au fil du temps de chacune des améliorations de ses briques sous-jacentes.
La dynamique Open Source suffit à confirmer la faisabilité technique de la réutilisation toutes technologies confondues. Surtout, elle valide son potentiel colossal. Alors pourquoi recense t’on si peu de succès dans les entreprises ou administrations ? Une première justification est le contexte politique et le poids de l’organisation que l’on y trouve. Sur ce point, de nombreux facteurs sont défavorables à la réutilisation :
– problème de confiance entre développeurs,
– difficulté d’imputation des coûts de capitalisation sur les projets,
– la réutilisation est rarement sur le chemin critique des chefs de projet,
– friction entre départements,
– …
Une deuxième justification provient du caractère générique des briques Open Source. La grande majorité répond en effet à des besoins fonctionnels communs (gestion de contenu Web, portail collaboratif …). Ceci rend l’établissement de spécifications beaucoup plus simple à réaliser.
Ce sont là les principaux freins à l’adoption d’une vraie démarche de réutilisation. Il appartient au management de faire sauter ces verrous. Il est en effet, urgent de favoriser la mutualisation tant au niveau de l’expression des besoins qu’au niveau des développements.
Il est urgent d’agir pour le management
Certaines campagnes publicitaires le martèlent: rendez votre système d’information agile. Au-delà de la réutilisation (décidément omniprésente …) marketing de cette tendance, il est temps d’agir pour le management. Une fois le diagnostic fait, c’est une véritable conduite du changement qu’il faut engager. Chacun doit progressivement adopter la pensée de Picasso « Les bons artistes plagient, les grands artistes pillent ! » et la transformer en réflexe.
Les problèmes liés à la politique interne se gèrent avant tout en identifiant clairement les gains et les coûts de la réutilisation. Ainsi, chacun est assuré que son travail est jugé en fonction d’objectifs définis et qu’aucun coût caché ne vienne perturber cette évaluation. On assure également qu’aucun mérite non justifié ne peut être tiré du travail des autres. Cette étape est fondamentale pour encourager le partage.
Les coûts de la réutilisation se décomposent de la manière suivante :
– Coût de réutilisation d’un composant : Le développeur doit assimiler le fonctionnement du composant, l’utiliser et tester son intégration avec son développement. On estime en moyenne le coût de réutilisation du composant à 20% de l’effort nécessaire pour le développer.
– Coût d’écriture d’un composant réutilisable : Par rapport, au développement d’une fonction « projet », le développeur doit généraliser le composant pour répondre à des besoins plus larges, ajouter une documentation détaillée, préparer le composant pour sa distribution, tester de manière plus approfondie. On estime à 50% ce coût par rapport au développement d’une fonction utilisée une seule fois.
Les bénéfices à attendre de la réutilisation sont :
– Une réduction de la production de code durant les développements : On comptabilise l’ensemble des fonctions fournies en standard par le framework.
– Une réduction de coût de service d’exploitation : la réutilisation limite les erreurs, simplifie les procédures d’exploitation des applications … donc réduit le coût d’exploitation des applications.
– L’établissement d’un socle technique évolutif : les briques communes vont pouvoir d’enrichir au fil du temps et fournir ainsi un niveau de service supérieur à l’ensemble des applications.
La mise en place d’une méthode permettant de suivre le retour sur investissement est ainsi une des premières étapes à suivre. Elle apporte les métriques qui fournissent au management la possibilité de piloter la réutilisation.
Pour être véritablement efficace, cette méthode et l’organisation à mettre en place doivent dissocier la notion de framework en deux :
– Le framework technique : il règle des problèmes techniques de manière uniforme tels que l’accès aux bases de données, la génération de PDF, la transformation de flux XML, l’accès aux systèmes d’authentification de l’entreprise, … L’utilisation de ces composants est obligatoire. Au même titre que le matériel, le système d’exploitation … ils doivent être perçus comme des composants incontournables de la plateforme d’exploitation.
– Le framework fonctionnel : il apporte des réponses aux besoins métier de l’entreprise. Ces besoins peuvent être génériques comme un framework de gestion de contenu Web et/ou plus spécifique comme un moteur de pricing dans le domaine de l’assurance, une carte de tournée pour les sociétés de livraison… Le framework fonctionnel doit bien évidemment reposer sur le framework technique.
Organiser les équipes en conséquence
Cette distinction est fondamentale. Nous estimons en effet, que la mise en œuvre du framework technique doit se faire en dehors de tout projet métier. Elle doit au même titre que les normes de développement être à la charge d’une équipe dédiée (éventuellement externalisée). Le management doit par ailleurs, imposer l’utilisation de ce framework par les projets. Son enrichissement dans le temps doit faire l’objet d’une mission spécifique sous une responsabilité identifiée. L’équipe en charge du framework technique gérera les problèmes de compatibilité ascendante, rendra transparents les changements d’infrastructure (passage d’un mécanisme d’authentification compte NT à un annuaire LDAP, par exemple) … Les développeurs technophiles sont généralement à l’aise dans un tel rôle.
Le coût de mise en œuvre du framework technique est en revanche à impacter aux projets puisque ces derniers en bénéficient. Une bonne solution consiste à imputer les projets d’un coût de framework de la même manière que les coûts matériels et logiciels.
Si la responsabilité du framework fonctionnel doit être centralisée pour en assurer la cohérence et la qualité, le développement de ses composants peut être gérée différemment. Un composant métier doit être enrichi d’une bonne connaissance métier souvent dans les mains des développeurs proches du fonctionnel. Le chef de projet rencontrant un nouveau besoin factorisable doit être incité à la création de ce composant sans que son développement impacte les coûts ni les délais de son projet. Dans ce cas, après concertation avec le responsable du framework, un budget de supplémentaire en temps et en coût (50% en général) peut être affecté à la réalisation de la fonction sous forme de composants réutilisable. Charge au responsable du framework et au chef de projet de mixer développeurs proches du fonctionnel et experts techniques pour atteindre l’objectif. Procéder de la sorte permet d’impliquer l’ensemble des équipes et de valoriser l’apport de chacun (technique et fonctionnel). Dans tous les cas, il faut veiller à ne pas mélanger les objectifs des équipes à un instant donné: capitaliser et livrer un projet en respectant des délais sont souvent incompatibles.
Conclusion
Aujourd’hui, nous disposons de tous les éléments techniques permettant la mise en œuvre d’une véritable démarche d’industrialisation. La réussite de ce projet n’est qu’une question de management. Au vu de son potentiel, une direction informatique doit renforcer ses efforts dans ce sens. Profitant de l’actuelle période de calme technologique, elle doit se fixer l’objectif ambitieux de la réutilisation. Ne pas le faire, la condamnerait à ne plus être elle-même réutilisée !
