Note: 4; Trop volumineux et pas du tout agile, mais avec certaines bonnes idées.

De prime abord, l’ouvrage attire l’attention : la gestion de configuration est une pièce essentielle de nos pratiques d’ingénierie, et en voire la mouture agile manquait cruellement jusqu’à présent. Mais comme nous allons le voir, il est plutôt curieux que cet ouvrage ait été édité dans la « Agile Software Development series », car il est résolument orienté processus.

Les 350 pages de ce volume sont structurées en 5 parties pour un total de 26 chapitres. C’est assurément une belle bête, toutefois bien rythmé. La première partie compte 5 chapitres pour environ 75 pages pour répondre à cette question : qu’est-ce que la gestion de configuration ? C’est par des définitions et un métamodèle que le premier chapitre tente de répondre à cette question. On y passe en revue des concepts tels qu’identification, stockage, change control… cela semble complet mais c’est surtout complexe !

On passe la seconde avec les modèles de maturité : CMMi d’abord puis SPICE ensuite, plus précisément dédié à la gestion de configuration mais sans un poil d’agilité. Un chapitre fort ennuyeux. Dans la même veine, le chapitre 3 nous présente les standards internationaux ! C’est plus ennuyeux encore, mais on sera sans doute content d’avoir un endroit où les retrouver… Le chapitre 4 est très court, il s’agit juste d’une évocation des organismes gravitant autour de ce sujet. Enfin cette première partie se referme sur une évocation des tâches liées à la gestion de configuration. Le propos n’est pas inoubliable.

La seconde partie se focalise plus précisément sur ce que nous allons mettre dans cette gestion de configuration. Cela nous occupe durant 4 chapitres pour une soixantaine de pages. Disons que ça commence en douceur avec un chapitre 6 consacré aux types d’objets que l’on va trouver en gestion de configuration, c’est moyennement intéressant. Ça l’est bien plus au chapitre 7, qui fait le tour des métadonnées liées aux éléments de configuration. A défaut d’être agile, c’est un tour d’horizon complet.
Nous abordons les formalismes au chapitre 8 : approbation, change requests et tous les formulaires qui vont avec. C’est une belle brochette bureaucratique, pour le moins. Toujours assez bureaucratique, mais plus intéressant : le chapitre 9 nous expose en quelques pages ce que l’on peut attendre d’un outil de configuration. C’est utile, à défaut d’être formidable et cela clôt cette seconde partie.

La 3ème partie est tout entière dévolue aux rôles gravitant autour de la gestion de configuration ! Ce sont 5 chapitres et près de 40 pages qui traitent de cela. Le chapitre 10 qui ouvre cette partie ne compte que quelques pages, pour introduire les chapitres suivants. Le chapitre 11 évoque les rôles liés au management et son infâme rejeton : le CCB ou Change Control Board. Ce n’est guère passionnant mais au moins on sait de quoi on parle. Ce sont les rôles dits organisationnels qui lui font suite au chapitre 12 : gestion des assets, du processus, des environnements, etc. Vraiment, je ne savais pas qu’il y en avait tant !

On arrive finalement aux rôles liés au projet au chapitre 13 ! Ils ne sont pas spécifiques à la gestion de configuration, mais l’auteure s’efforce de les décrire sous cet angle, ce qui est plutôt poussif. Les rôles externes referment cette partie un peu famélique et d’ailleurs on ne s’éternise guère sur ce dernier sujet.
Avec 7 chapitres pour une centaine de pages, on n’attaque vraiment le cœur du sujet avec la 4ème partie justement intitulée « configuration management in practice ». Le chapitre 15 nous présente les principes généraux et nous espérons que cela va s’améliorer par la suite. Pour l’instant on nous parle d’approbation, d’identification, de contrôle des changements et de traçabilité… Le chapitre 16 va se focaliser sur les activités liées au développement. Ici, il est surtout question de nomenclature, d’identification des artéfacts et d’autorisations. S’il y avait une goutte d’agilité, ce serait ici qu’on devrait la trouver, mais non ! Un chapitre peu enthousiasmant ressemblant plutôt à un guide de référence. Le chapitre 17 nous assène le même traitement pour les artefacts du de la gestion de projet : plans, release notes, définition des jalons, etc. Difficile d’avoir envie de s’y arrêter.

Au chapitre 18, il va être question de différents modèles de développement, et justement on commence par le modèle agile ! Néanmoins, le texte s’il évoque de manière juste le développement agile, n’apporte aucun éclairage particulier sur le volet gestion de configuration. L’integrated product development du SEI semble mieux maitrisé par l’auteur, même s’il est plus légèrement traité. Les modèles en spirale et en cascade font aussi partie du paysage mais toujours sans prisme spécifique à la gestion de configuration. Le chapitre 19 nous apporte un peu de variété en évoquant comment différents types de produits peuvent être traités en gestion de configuration : Web, critiques, composites, multi-plateforme…

Le chapitre 20 nous emmène vers des sujets plus avancés : développements multisites, en parallèle, etc. Les réponses apportées ont pris des rides mais au moins l’auteure nous propose des stratégies adaptées à l’époque. Le chapitre 21 qui clôt cette partie s’inscrit quelque peu dans cette continuité, avec la gestion d’assets transverses ou partagés. Là aussi l’auteure nous propose des stratégies adaptées par exemple aux lignes de produits, mais dépassées aujourd’hui.

La 5ème partie, qui comporte 5 chapitres sur 55 pages, va traiter pour l’essentiel des niveaux de maturité de la gestion de configuration. Il n’est donc pas étonnant que le chapitre 22 soit consacré au niveau 1. A ce stade les attentes sont assez basiques : mettre en œuvre la gestion de configuration, être capable d’identifier les objets en gestion de configuration et assurer leur intégrité ! Le niveau 2, sujet du chapitre 23, est plus exigent et demande un plan de gestion de configuration, par exemple, et quelques autres éléments à caractère plutôt administratifs.

Au chapitre 24, c’est le niveau 3 qui est abordé : il ajoute essentiellement un processus de gestion de configuration. Nous voyons bien que nous n’allons pas dans le sens d’une légèreté croissante… Le chapitre 25 couvre les niveaux 4 et 5, peut-être parce que l’on commençait à s’ennuyer très fort ? Il est question de métriques pour initier l’amélioration des pratiques. En réalité, c’est loin d’être inintéressant… Le livre se referme sur un chapitre 26 qui traite des outils. Un chapitre plutôt dédié aux managers, car il n’y est guère question de fonctionnalités et de caractéristiques d’outils mais plutôt de stratégie d’acquisition !

L’ouvrage est résolument old school et accuse son âge. Dans sa catégorie, le style est plus intéressant et concret que ce que l’on a l’habitude de trouver dans ce type d’ouvrage, avec quand même des éléments concrets. Il reste que le livre a un peu de mal à justifier ses 350 pages (250 auraient suffi, je pense), et qu’il est d’avantage orienté vers les processus convergent vers CMM que vers les démarches agiles, comme cela est suggéré. Dans l’ensemble, ma note de « 4 » est plutôt bien payée.

Référence complète : Configuration Management Principles and Practices – Anne Mette Jonassen Hass – Addison Wesley / ASD series 2003 – ISBN: 0-321-11766-2