Périmètre & exigences

Définir le périmètre d'un projet ne se limite pas à lister les livrables du contrat. Il faut structurer, dès le départ, à la fois ce qui est engagé vis-à-vis du client et tout ce qu'il faut produire en interne pour tenir cet engagement. La partie contractuelle est la face émergée de l'iceberg. Elle représente rarement la majorité du travail à effectuer. La face immergée est plus grande et concentre la majorité des difficultés d'exécution. L'identification de cette partie induite est primordiale. **La face émergée : le WBS contractuel.** Le WBS (Work Breakdown Structure) contractuel est le référentiel de base. Il décompose l'ensemble des engagements formalisés dans le contrat en composantes homogènes et pilotables. Six familles cohabitent typiquement, et confondre leur nature crée des angles morts. - **Les livrables physiques** : le produit lui-même et ses quantités. Selon les projets, un ou plusieurs exemplaires, avec ou sans variantes. - **Les livrables documentaires** : dossiers de définition, notices d'utilisation, dossiers de conformité, manuels de maintenance. Souvent sous-estimés en charge, ils peuvent représenter une part significative du planning. - **Les activités contractuelles** : ateliers de travail avec le client, comités de pilotage, revues formelles, jalons de validation. Ce ne sont pas des livrables au sens matériel, mais leur non-tenue engage la responsabilité du fournisseur. - **Les services** : maintenance, support, prestations d'exploitation, hotline. Ils courent souvent après la livraison et allongent la durée d'engagement contractuel bien au-delà de la mise en service. - **Les formations et transferts de compétence** : quand le produit livré est destiné à être exploité par le client, un volet formation contractuel accompagne presque toujours la livraison. Sous-estimer ce volet est un classique. - **La recette, la qualification, l'homologation** : les livrables contractuels qui certifient que le produit répond aux exigences. Ils supposent souvent des campagnes d'essais lourdes, des documents d'accompagnement précis, et l'implication de tiers (laboratoires, autorités de certification). **La face immergée : les artéfacts induits.** La partie contractuelle n'est que la face émergée. Livrer un produit conforme à un contrat suppose de produire une quantité importante d'artéfacts qui ne figurent nulle part dans les engagements mais sans lesquels rien ne peut être livré. - **Les documents d'ingénierie intermédiaires** : études, calculs, plans de définition, dossiers de justification. Ils précèdent et conditionnent les livrables documentaires contractuels. - **Les moyens d'IVV (intégration, vérification, validation)** : bancs d'essai, prototypes, échantillons, moyens de mesure, plateformes d'intégration, environnements de test. Souvent développés spécifiquement pour le projet, ils conditionnent la capacité à assembler et valider progressivement les composants avant la recette contractuelle. C'est un pan de travail massif, régulièrement sous-estimé au moment de l'engagement contractuel. - **Les outillages de production** : moyens dédiés, gabarits, jigs, moules. Investissements amont significatifs, avec leurs propres délais de fabrication et de qualification. - **Les artéfacts de reprise d'antériorité et de conversion de données** : quand le projet s'inscrit dans un existant à faire évoluer, la migration des données et la reprise de l'antériorité sont massivement sous-estimées, particulièrement quand les acteurs se rassurent en invoquant du "réutilisable". - **Les artéfacts liés aux pratiques internes** : documents qualité, dossiers de gouvernance interne, revues obligatoires par l'organisation. - **Les artéfacts liés aux normes, à la réglementation et à la sûreté** : dossiers de conformité, rapports d'audit, dossiers de sûreté de fonctionnement, dossiers de cybersécurité. Certains niveaux d'exigence issus de normes de sûreté (SIL 4 en sûreté fonctionnelle IEC 61508, DAL A en avionique DO-178C, ASIL D en automobile ISO 26262) peuvent doubler le périmètre et le coût d'un projet, sans changer un seul livrable contractuel. La maîtrise du périmètre passe donc par la maîtrise conjointe de ces deux faces : ce qui est engagé et tout ce qu'il faut produire pour tenir l'engagement. Un projet qui ne cartographie que la face émergée découvre la face immergée en cours de route, et la découverte se paie en dérive de délai et de coût.

Sur un projet, les variations de périmètre sont la règle, pas l'exception. Le contexte évolue, la connaissance du besoin s'affine, les contraintes techniques se révèlent, les décisions de tiers s'imposent. Prétendre empêcher toute variation est irréaliste. La discipline consiste à disposer d'un cadre qui absorbe ces variations sans perdre le contrôle du projet, en distinguant clairement ce qui relève d'un vrai changement de ce qui relève d'un oubli initial mal assumé. **La mécanique du change request.** Un change request formalisé est le sas obligatoire de toute demande de modification du périmètre engagé. Il porte une demande précise, une justification, et une évaluation d'impact triple : sur le périmètre (que change-t-on exactement), sur le délai (quelle bascule sur le calendrier, quel déplacement du chemin critique), sur le coût (quelle imputation, quel montant). Sans cette évaluation triple, la décision d'accepter ou de refuser se prend à l'aveugle. Une fois validé, le change request se traduit dans la très grande majorité des cas par un avenant au contrat client, qui abonde le budget projet du montant correspondant, et s'impute sur un budget de change dédié, distinct du budget de base. Le cas d'une consommation sur une réserve budgétaire préexistante sans avenant est rare : il suppose qu'une enveloppe de change ait été explicitement provisionnée à l'engagement contractuel initial, ce qui reste peu fréquent en pratique. Cette distinction budget de base / budget de change permet ensuite de tracer précisément la part de la trajectoire financière due à des évolutions de périmètre par rapport à celle due à la consommation du périmètre initial. **L'arbitrage change vs oubli.** Une part significative des demandes présentées comme des changements sont en réalité des éléments qui auraient dû figurer dans le périmètre initial. Cette distinction n'est pas académique : elle a une conséquence contractuelle et financière directe. Un vrai changement, décidé par le client après validation initiale, est légitimement imputable au budget de change et facturable. Un oubli initial, en revanche, relève d'une insuffisance de définition amont, et le partage de la charge financière devient une négociation. Un projet qui accepte toutes les demandes sans faire cette distinction voit son budget de change gonfler, mais surtout perd la trace de sa qualité de définition initiale, qui est un signal utile pour les projets suivants. **La gouvernance du change.** Une gestion propre suppose une instance clairement identifiée qui traite les change requests à cadence définie, avec un pouvoir de décision explicite. Faute de quoi, les demandes s'accumulent en file d'attente, les équipes bricolent sans mandat, et le périmètre bouge de facto sans qu'aucune décision formelle ne l'ait acté. La gouvernance du change n'est pas un formalisme bureaucratique, c'est la condition pour que le périmètre réellement livré coïncide avec le périmètre réellement engagé.

Dans les projets longs et exploratoires, il est fréquent que le périmètre soit engagé avant que toutes les exigences ne soient complètement figées. C'est une réalité incontournable des projets longs et exploratoires : attendre que tout soit stabilisé pour démarrer, c'est ne jamais démarrer. La discipline consiste à organiser explicitement la maturation des exigences dans le temps, et à protéger les équipes contre le travail sur des bases instables. **Un plan de décision aligné sur les besoins d'artéfacts.** L'idée fondamentale est de définir à l'avance quelle exigence doit être figée à quelle date, en fonction de ce qui doit être libéré en aval. Sur un véhicule blindé par exemple, les épaisseurs de tôle doivent être figées un ou deux ans avant le design détaillé pour lancer les coulées d'acier. Ce n'est pas une contrainte artificielle : c'est la conséquence directe du délai d'approvisionnement du matériau, qui remonte dans le calendrier tous les jalons d'exigence associés. Le plan de décision ne se construit pas depuis l'aval en descendant chronologiquement ; il se construit en identifiant les jalons irréversibles et en remontant vers les exigences qu'ils supposent figées. **Des livrables en versions de maturité étagées.** Plutôt que d'attendre la version définitive de chaque livrable, on organise leur production en versions successives dont la maturité augmente : version A (concept), version B (préliminaire), version C (définitif), avec un contenu explicite à chaque version. Chaque version documente l'état des exigences figées et l'état des exigences encore ouvertes. Les équipes savent sur quelle version elles travaillent, et ce qui est stable ou pas dans leur base de travail. Cette pratique évite le piège des travaux menés sur une base implicite qui change en cours de route sans qu'on s'en aperçoive. **Le principe de priorité aux exigences figées.** Les équipes doivent, dans la mesure du possible, ne travailler que sur des exigences figées. Quand ce n'est pas possible et qu'un travail doit être engagé sur une exigence non encore figée, cette dépendance doit être tracée explicitement : quel artéfact repose sur quelle exigence, à quelle version. Sans cette traçabilité, on découvre après coup que trois mois de travail sont à reprendre parce qu'une exigence amont a bougé. **La traçabilité documentaire comme colonne vertébrale.** Chaque exigence doit pouvoir être remontée vers l'exigence de plus haut niveau dont elle dérive, et chaque design vers la version d'exigence sur laquelle il repose. Cette matrice de traçabilité (formalisée notamment dans l'INCOSE Systems Engineering Handbook et dans la norme ISO/IEC/IEEE 29148 sur l'ingénierie des exigences) est ce qui permet, lorsqu'une exigence bouge, d'identifier immédiatement tous les artéfacts en aval qui sont impactés, et donc à reprendre ou à revérifier. Sans matrice, l'impact d'un changement d'exigence se découvre en marchant sur les mines.