Qui n’a jamais vécu ça dans le quotidien d’un projet ? On est en réunion, on parle, on discute, on n’avance pas, sans vraiment savoir pourquoi. On a l’impression de ne pas se comprendre. Cela peut avoir de nombreuses raisons, et l’une des principales candidates est l’absence d’une compréhension commune des termes employés.
L’un de ces termes est le mot configuration, qui peut avoir des significations très différentes selon le contexte :
- Configuration des variantes
- Configuration au sens d’une gestion de configuration
- Configuration au sens d’un paramétrage
Pour ajouter à la confusion : il arrive qu’un même projet ou processus soit confronté aux trois interprétations à la fois, et qu’elles soient en plus liées entre elles d’une manière ou d’une autre. J’y reviendrai plus tard.
Origine du mot
cōn-fīgere (latin) assembler, clouer ensemble
Le préfixe con- signifie « ensemble » en latin. Et figere, on s’en doute, veut dire « ficher », « fixer », « attacher ». Une « figure » n’est donc rien d’autre qu’une chose « fixée » 😉. Et une configuration est donc quelque chose « d’assemblé », ou plus précisément, l’action d’assembler.
Dans une configuration, j’assemble donc des éléments individuels pour former quelque chose de plus grand. Et avec un peu de recul, cela vaut d’ailleurs aussi pour les trois significations.
Différentes significations de « configuration »
1. Configuration des variantes
Là aussi, un détour par le dictionnaire aide : en latin, variare signifie « colorer », « varier », « teinter ». La variante est donc une « coloration » particulière de mon produit, ou la coloration d’un composant de mon produit. Et c’est exactement de cela qu’il s’agit dans la configuration des variantes : j’assemble (moi, en tant que client par exemple) des composants « colorés » individuellement (des variantes) pour former un produit (assemblage = configuration).
Un exemple ? Je configure une variante de vélo. Pour le cadre, je voudrais la « coloration » vélo de trekking homme, 54 cm. La coloration n’est bien sûr pas à prendre au sens littéral ici, il s’agit de la variante du cadre. Ensuite, la transmission en variante 21 vitesses, la selle en gel, et le tout en bleu marine (cette fois, la coloration est même littérale).
Voilà, nous avons assemblé, à partir des variantes individuelles des composants, une (parmi de très nombreuses possibles) variante de vélo — autrement dit, nous l’avons « configurée » 👍.
À proprement parler, je pense que dans de nombreux cas, il faudrait d’ailleurs plutôt parler de sélection de variantes que de configuration de variantes. Mais c’est un autre sujet, sur lequel j’écrirai sûrement aussi un jour 😉.
2. Gestion de configuration (par exemple ISO 10007)
Qui interroge le moteur de recherche de son choix trouvera diverses définitions (par exemple ISO 10007 ou ANSI/EIA-649). En voici un exemple tiré de l’ANSI :
La gestion de configuration est un processus de management visant à établir et à maintenir la cohérence entre les performances du produit ainsi que ses caractéristiques fonctionnelles et physiques, les exigences, la conception du produit et les informations opérationnelles, tout au long du cycle de vie du produit.
J’aime beaucoup cette définition de l’ANSI, car elle contient des affirmations importantes :
- Il s’agit d’un processus de management
- Il garantit que le produit est conforme à ses exigences
- … et tout cela pendant tout le cycle de vie du produit.
Peu importe la norme sur laquelle on s’appuie, le principe est toujours le même : lorsque nous sommes responsables d’un produit, nous devons d’abord déterminer quels « éléments » sont importants pour nous (les fameuses unités de configuration). La notion d’élément peut et doit être comprise au sens large, c’est-à-dire que l’on ne regarde pas seulement les composants physiques (pièces) d’un produit, mais aussi toutes les informations importantes dans le cadre du développement (et de l’ensemble du cycle de vie). Donc les exigences, les plans, les spécifications, etc. — L’identification de ces unités de configuration pertinentes s’appelle, dans le jargon des normes, très justement l’identification de configuration. La configuration est alors l’ensemble des unités de configuration que nous avons identifiées dans le cadre de l’identification de configuration. C’est clair jusqu’ici ? 😉
Voici un exemple — certes anachronique et peu numérisé, mais le principe est là :
Ingo, ingénieur en chef chez un fabricant de vélos, doit développer un nouveau vélo. Pour avoir une gestion de configuration en bonne et due forme, il commence (ou plutôt son apprenti Anton) par créer un classeur avec différents onglets, qui pourraient être :
- Exigences
- ISO 4210 (norme pour la construction de vélos)
- Exigences commerciales (ce que veulent les clients)
- Spécification
- Cadre
- Système de freinage
- Transmission/dérailleur
- Documents de fabrication
- Plan de soudage du cadre
- Instructions de montage
L’identification de configuration serait ainsi terminée, la configuration créée. Dans les différents onglets, les informations actuellement en vigueur sont ensuite classées peu à peu. Dans l’onglet ISO 4210, on trouvera donc l’ISO 4210:2023, la version actuelle de la norme de construction des vélos. Un peu plus tard, une fois que les concepteurs responsables auront terminé leur travail, on y ajoutera aussi les plans de construction du cadre, du frein, etc.
Entre-temps, Anton (l’apprenti) a le droit de photocopier tout le classeur une fois par semaine et de le ranger aux archives (snapshot). Au plus tard lorsque le développement est terminé et que le degré de maturité de la spécification a été validé par Ingo, l’ingénieur en chef, le classeur ainsi photocopié reçoit, au gros feutre rouge, la mention « construction validée » (baseline AS-DESIGNED).
Comment la gestion de configuration garantit exactement qu’un produit respecte ses exigences, et ce que tout cela a à voir avec la traçabilité… j’en dirai aussi plus une prochaine fois !
3. Paramétrage d’un produit intelligent
Définir son fond d’écran préféré dans le système d’exploitation Windows, adapter le système de CAO aux besoins de son entreprise, ou saisir la taille de roue dans le compteur de vélo pour que la vitesse s’affiche correctement. Dans le langage courant, tout cela relève aussi du terme « configurer ». Pour revenir au contexte de l’origine du mot « configuration » : on pourrait dire que l’on assemble les différents interrupteurs et leviers de réglage que le produit propose.
Un terme peut-être plus adapté que configuration à cet endroit est paramétrage. Mon produit (logiciel) me propose différents interrupteurs et options de réglage pour lesquels je peux définir un paramètre. Dans le cas du vélo (ou de son compteur), il s’agit même d’un produit composé d’éléments logiciels et électromécaniques. Ceux qui ont beaucoup affaire à Linux connaissent les fichiers *.conf (comme configuration), et certains se souviennent peut-être encore des fichiers .ini sous Windows. Mais le principe est toujours le même. En définissant des interrupteurs, on peut influencer le comportement du logiciel ou du produit.
Assemblage (😉) de ce qu’on a appris
Nous avons appris dans les sections précédentes que le mot « configuration » peut être utilisé dans des contextes très différents. Dans l’introduction, j’ai écrit que, pour ajouter à la confusion générale, les trois contextes peuvent aussi se retrouver ensemble dans un même projet ou processus. Comme promis, quelques mots à ce sujet aussi.
Ou d’abord un exemple :
Viktor, du service commercial, a inscrit dès le départ dans le cahier des charges destiné à l’ingénieur Ingo que le vélo devait pouvoir être commandé avec un cadre femme et un cadre homme, ainsi qu’en différentes tailles de cadre. Il fallait trois tailles de disque de frein différentes, et pour la transmission, le client devait pouvoir choisir entre 21 et 27 vitesses. Et hop, l’élément de configuration « cadre » de la configuration issue de la gestion de configuration est lui-même soumis à une configuration (de variantes) 😉
Cela conduit naturellement à avoir des plans de construction différents (= variants) pour les différents cadres, et donc aussi des références et numéros de matériel différents, permettant d’identifier ces différents cadres dans le processus logistique.
Si le fabricant de vélos est très rigoureux, il fera faire par l’apprenti Anton, une fois que j’aurai commandé mon vélo, une nouvelle photocopie du classeur dans le cadre de la gestion de configuration, avec la mention AS-ORDERED by Julian Weyer. Tout ce que j’ai commandé (vélo de trekking homme, 54 cm, selle en gel, transmission 21 vitesses, bleu marine, on se souvient) est surligné au feutre dans ma baseline, toutes les variantes que je n’ai pas commandées sont rayées ou retirées du classeur (que je voie moi-même un jour cette photocopie du classeur relève d’un autre débat, mais c’est le principe qui compte).
Les différents paramètres (dans le langage courant, donc la configuration) du compteur de vélo peuvent eux aussi être des unités de configuration au sens de la gestion de configuration. Autrement dit : avant la livraison du vélo, le monteur qui a effectué le montage et le paramétrage classe également les données de paramètres dans mon classeur photocopié, afin que l’on puisse toujours savoir dans quel état j’ai reçu mon vélo (AS-DELIVERED).
Cela semble compliqué et déroutant ? En réalité, je trouve tout cela plutôt logique et cohérent — à condition d’avoir conscience de ces différents aspects et de bien situer chacun dans son contexte de projet. En cas de doute, mieux vaut demander une fois de trop :
💬 Qu’entendez-vous exactement par « configuration », quand vous en parlez ?
