Dans l’industrie automobile, la sélection d’un fournisseur de composants logiciels ne repose plus uniquement sur le prix ou le délai. Les constructeurs comme BMW, Audi et Volkswagen exigent désormais que leurs équipementiers démontrent un niveau de maturité processus vérifié selon le référentiel Automotive SPICE (ASPICE). Pour un chef de projet qui travaille dans cette chaîne de valeur ou qui envisage d’y entrer, comprendre ce que cette exigence implique au quotidien est devenu indispensable.
Qu’exigent concrètement les constructeurs?
Automotive SPICE est un référentiel d’évaluation de la maturité des processus de développement, publié par le VDA QMC (l’organisme qualité de l’association des constructeurs automobiles allemands). Il évalue la capacité d’une organisation à développer des logiciels, du matériel et des systèmes de manière fiable et reproductible. La version 4.0, publiée fin 2023, couvre désormais aussi le développement matériel et l’apprentissage automatique.
Le référentiel définit six niveaux de capacité, de 0 (processus inexistant) à 5 (optimisation continue). En pratique, le niveau 2, dit “géré”, est le minimum exigé par la plupart des OEM (constructeurs) pour accorder un contrat. Un fournisseur qui n’atteint pas ce niveau lors d’un audit voit son contrat menacé ou ses nouveaux projets attribués à un concurrent. Le niveau 3, où les processus sont standardisés dans toute l’organisation, est considéré comme le standard d’excellence, mais peu de fournisseurs l’atteignent de manière uniforme sur l’ensemble de leurs processus.
Le processus MAN.3: la gestion de projet sous la loupe
Parmi les processus évalués par ASPICE, MAN.3 (Project Management) est celui qui concerne le plus directement le chef de projet. Pour atteindre le niveau 2 sur ce processus, il faut démontrer que plusieurs pratiques sont en place et produisent des résultats vérifiables.
Le plan de projet doit exister, être maintenu à jour et couvrir les activités, les jalons, les estimations d’effort et les ressources nécessaires. Les risques doivent être identifiés, évalués et suivis dans un registre. L’avancement doit être mesuré par rapport au plan, avec des écarts documentés et des actions correctives tracées. Les interfaces avec les parties prenantes (stakeholders) et les fournisseurs doivent être formalisées par des accords écrits.
Cette exigence de formalisation peut sembler lourde pour un chef de projet habitué à gérer par communication directe. La réalité est que l’auditeur ASPICE ne vérifie pas la sophistication des outils utilisés: un tableur de suivi des risques suffit, à condition que les entrées soient datées, les responsabilités attribuées et les revues documentées. Ce qui compte, c’est la cohérence entre ce qui est planifié, ce qui est exécuté et ce qui est tracé.
ACQ.4: surveiller ses propres fournisseurs
Le second processus critique pour le chef de projet est ACQ.4 (Supplier Monitoring). Dans l’automobile, les chaînes de sous-traitance sont longues: un équipementier de rang 1 confie régulièrement des modules logiciels à des fournisseurs de rang 2 ou 3. Le chef de projet du rang 1 doit alors organiser la surveillance de ces sous-traitants selon les mêmes critères ASPICE que ceux auxquels il est lui-même soumis.
Cela implique des revues techniques régulières, des audits de processus chez le fournisseur, un suivi des livrables contractuels et une gestion des écarts formalisée. En cas de défaillance d’un sous-traitant, c’est l’équipementier de rang 1 qui en porte la responsabilité devant le constructeur. Le chef de projet se retrouve donc dans un rôle de garant de la qualité processus sur toute sa chaîne d’approvisionnement.
Comment concilier ASPICE et agilité?
ASPICE et les méthodes agiles sont compatibles, à condition de comprendre ce que le référentiel évalue réellement. Le référentiel repose sur le modèle en V, une structure de développement dans laquelle chaque phase de spécification (côté gauche) possède une phase de vérification correspondante (côté droit), garantissant la traçabilité des exigences jusqu’aux tests d’acceptation. Cette architecture peut donner l’impression d’imposer un cycle de développement séquentiel.
Cette impression est trompeuse: ASPICE évalue les résultats des processus, pas la chronologie dans laquelle les activités sont réalisées. Une équipe qui travaille en sprints peut tout à fait satisfaire les exigences de traçabilité bidirectionnelle entre exigences, conception et tests, à condition d’instrumenter ses outils en conséquence: liens automatiques entre user stories et cas de test, rapports de couverture générés à chaque itération, revues de conception intégrées aux cérémonies Scrum.
La difficulté principale réside dans la documentation: les auditeurs ASPICE cherchent des preuves objectives (work products) de chaque activité. Le piège classique consiste à sous-estimer cet effort et à tenter de reconstituer la documentation après coup, ce qui génère un travail considérable et des incohérences. L’approche efficace consiste à intégrer la production de traces dans le flux de travail quotidien dès le début du projet.
Les erreurs courantes lors de la mise en conformité
La mise en conformité ASPICE échoue fréquemment pour des raisons qui relèvent davantage de la gestion de projet que de l’ingénierie logicielle. Des objectifs de niveau mal définis conduisent les équipes à viser le niveau 3 alors que le niveau 2 suffirait pour répondre aux exigences contractuelles. Des calendriers trop ambitieux compriment la phase de préparation et laissent les équipes sans formation adéquate. L’absence d’implication de la direction prive le projet des ressources nécessaires.
Le facteur humain joue également un rôle déterminant: les équipes de développement perçoivent parfois les exigences ASPICE comme une contrainte bureaucratique imposée de l’extérieur, sans comprendre leur finalité. Le chef de projet a la responsabilité de contextualiser cette démarche en montrant que la formalisation des processus réduit les reprises tardives, facilite l’intégration des nouveaux membres et améliore la prévisibilité des livrables.