Gestion de projets d’automatisation : piloter des projets de PLC, SCADA et contrôle-commande de l’URS à la mise en service

Qu’est-ce que la gestion de projets d’automatisation

La gestion de projets d’automatisation est la discipline qui consiste à planifier, exécuter, coordonner et livrer des projets d’automatisation industrielle installant, configurant et intégrant des systèmes de contrôle-commande (PLC, SCADA, DCS, systèmes de sécurité) dans une usine de production ou une installation de procédé. Elle se situe à l’intersection de la gestion de projets d’ingénierie, de la gestion de projets IT et de la gestion de projets d’exploitation, puise dans les trois sans se réduire à aucune, car les projets d’automatisation présentent des traits propres que les approches génériques de gestion de projet ne couvrent pas entièrement.

La définition et la place des projets d’automatisation

Un projet d’automatisation commence lorsqu’une organisation de fabrication décide d’installer une nouvelle technologie de contrôle-commande ou de moderniser des systèmes existants, et se termine lorsque le système installé fonctionne de façon sûre et fiable en production et satisfait les exigences d’exploitation définies au départ. Le périmètre comprend en général la sélection et l’approvisionnement du matériel, la configuration et la programmation du logiciel, l’intégration avec les systèmes d’usine existants, les essais en plusieurs étapes, la validation de la sécurité et de la cybersécurité, la formation des opérateurs et le transfert formel à l’exploitation. Les types de projet fréquents sont les installations greenfield (usine neuve, sans héritage), les modernisations brownfield (remplacement de systèmes de contrôle-commande obsolètes sur une usine en marche), les extensions de capacité (nouvelles lignes de production dans une architecture d’automatisation existante) et les mises à niveau des systèmes de sécurité (amener des installations existantes aux normes en vigueur comme l’IEC 61511 Édition 2).

Ce qui les distingue des projets de fabrication habituels

Un projet d’automatisation n’est pas un projet de fabrication habituel, même s’il se déroule au sein d’une entreprise de production. Quatre différences sont déterminantes. Premièrement, le résultat est un système et non un produit : on obtient une architecture d’automatisation en fonctionnement, et non un produit unique prêt à vendre, de sorte que les critères de réussite portent sur la performance d’exploitation et non sur les caractéristiques d’un produit. Deuxièmement, le travail est multidisciplinaire par nature d’une manière que ne sont pas les projets de fabrication ordinaires : mécanique, électricité, logiciel de contrôle-commande, infrastructure IT et ingénierie de procédé doivent converger vers la même date d’installation, souvent avec des prestataires différents responsables de disciplines différentes. Troisièmement, l’ordre de validation est impératif et irréversible : FAT avant SAT avant mise en service, sans raccourci possible, car les dépendances physiques imposent la séquence. Quatrièmement, les exigences de sécurité et de conformité portent souvent un poids réglementaire que les projets de fabrication génériques ne rencontrent pas avec la même intensité, des normes de sécurité fonctionnelle aux exigences de cybersécurité en passant par les réglementations sectorielles.

Ce qui les distingue des projets IT

Les projets d’automatisation sont parfois gérés à tort comme des projets IT, parce que les deux comportent du logiciel. Les différences sont considérables. Les projets IT autorisent en général le déploiement itératif, la mise à disposition par étapes à des sous-ensembles d’utilisateurs et les correctifs après la mise en production. Les projets d’automatisation se déploient dans une installation physique où le logiciel commande des procédés physiques aux conséquences réelles : corriger à chaud un PLC dans un réacteur chimique n’est pas le même type de changement que corriger une application web. Les projets IT peuvent être mis en pause ; les usines en marche, souvent non. L’échec d’un projet IT entraîne en général une perte de données ou une gêne pour l’utilisateur ; l’échec d’un projet d’automatisation peut provoquer des incidents de sécurité, des rejets environnementaux ou des manquements réglementaires. C’est pourquoi la discipline FAT-SAT-mise en service existe et pourquoi la raccourcir engendre des conséquences coûteuses que les chefs de projet IT ne perçoivent pas toujours au début.

Les six phases d’un projet d’automatisation : de l’URS à la mise en service

Les projets d’automatisation suivent une structure établie en six phases devenue standard dans tous les secteurs : chimie, pharmacie, agroalimentaire, énergie et fabrication générale. Les phases sont : spécification des besoins utilisateur (URS), spécification de conception fonctionnelle et détaillée (FDS, DDS), ingénierie et construction, essai d’acceptation en usine (FAT), installation et essai d’acceptation sur site (SAT), et mise en service. Chaque phase a des entrées, des sorties et des critères de jalon définis, et la discipline consistant à faire respecter les critères de jalon entre les phases sépare les projets d’automatisation livrés à temps de ceux qui épuisent leur budget en reprises tardives.

Phase 1 : spécification des besoins utilisateur (URS)

L’URS définit ce que le système d’automatisation doit accomplir du point de vue de l’exploitation : débit de production visé, spécifications produit, philosophie de commande, exigences de sécurité, contraintes réglementaires, attentes de l’interface opérateur et points d’intégration avec les systèmes d’usine existants et l’IT d’entreprise. Une URS bien rédigée, à l’image d’une charte de projet, est fonctionnelle et non technique : elle décrit le résultat souhaité sans prescrire la solution technique. La qualité de l’URS est le meilleur prédicteur isolé des résultats d’un projet d’automatisation, car chaque phase ultérieure hérite de l’ambiguïté ou de l’exhaustivité de ce document. Les projets qui sautent l’URS ou la traitent comme une formalité découvrent à répétition, au SAT ou à la mise en service, que différentes parties prenantes avaient des hypothèses différentes sur des fonctions de base, et à ce stade le coût de l’alignement est supérieur de plusieurs ordres de grandeur à ce qu’il aurait été en phase d’URS.

Phase 2 : spécification de conception fonctionnelle et détaillée (FDS, DDS)

La FDS traduit l’URS en une conception fonctionnelle : quel PLC, quel SCADA, quelle topologie réseau, quelles boucles de régulation, quelles fonctions de sécurité, quelles alarmes et comment elles se relient entre elles et à l’infrastructure d’usine. La DDS descend ensuite au niveau de détail technique nécessaire à l’ingénierie et à l’approvisionnement : modèles matériels précis, comptages d’E/S, plans de câblage, agencement des armoires, architecture logicielle, maquettes d’écrans HMI. Les phases FDS et DDS comportent des revues de conception avec le client, et l’approbation à la fin de la DDS est l’équivalent du gel de conception du projet d’automatisation. Les modifications ultérieures à ce point exigent une gestion formelle des changements et allongent en général l’échéancier.

Phase 3 : ingénierie et construction

L’ingénierie et la construction couvrent l’approvisionnement du matériel, le montage des armoires, le développement logiciel (code PLC, vues SCADA, logique de sécurité, configuration de l’historian), l’installation de l’infrastructure réseau et le montage mécanique et électrique sur site. Cette phase se déroule en parallèle entre plusieurs disciplines et fournisseurs, et c’est là que la coordination interdisciplinaire consomme l’essentiel de l’attention du chef de projet. Les composants à long délai d’approvisionnement identifiés durant la FDS (instruments spéciaux, automates certifiés de sécurité, équipements réseau spécialisés) doivent avoir été commandés assez tôt pour que l’ingénierie avance sans attendre le matériel. Le développement logiciel pour PLC et SCADA se fait en général après la DDS, en parallèle de l’approvisionnement matériel, afin que les deux soient prêts ensemble pour le FAT.

Phase 4 : essai d’acceptation en usine (FAT)

Le FAT se déroule dans les locaux du fournisseur ou de l’intégrateur, avant l’expédition vers le site. Le système de contrôle-commande complet (matériel PLC, logiciel SCADA, systèmes de sécurité) est monté et testé dans un environnement contrôlé avec des entrées et sorties simulées. Le FAT valide que le matériel est conforme à la DDS, que le logiciel met correctement en œuvre la logique fonctionnelle, que les alarmes et les verrouillages se comportent comme conçus, que les vues HMI affichent les informations spécifiées et que l’intégration entre sous-systèmes fonctionne. Le FAT est la dernière occasion rentable de détecter des défauts : les corrections au FAT coûtent environ dix fois moins que les mêmes corrections au SAT et cent fois moins que les défauts détectés à la mise en service. Sauter ou raccourcir le FAT est la cause isolée la plus fréquente de dépassements coûteux en automatisation.

Phase 5 : installation et essai d’acceptation sur site (SAT)

Après l’approbation du FAT, le système est expédié vers le site, installé par des prestataires mécaniques et électriques, et passe le SAT. Le SAT vérifie que l’installation est conforme aux plans, que les E/S physiques sont correctement raccordées aux instruments et actionneurs, que l’intégration avec les systèmes d’usine existants fonctionne comme conçu et que les essais fonctionnels de bout en bout réussissent dans les conditions réelles d’installation. Pour les projets SCADA et de procédé continu, le SAT comporte souvent un essai prolongé d’une à deux semaines pour démontrer un fonctionnement stable sans incident majeur. Lorsque plusieurs sous-systèmes de fournisseurs différents doivent être testés ensemble, un essai d’intégration sur site (SIT), formellement introduit dans l’IEC 62381:2024, est réalisé après les SAT individuels pour démontrer le fonctionnement intégré.

Phase 6 : mise en service

À la mise en service, le système validé est transféré vers la production en marche. La mise en service à froid teste les systèmes sans matière de procédé ou avec des fluides inoffensifs. La mise en service à chaud introduit progressivement de la matière de procédé réelle, avec réglage des boucles de régulation et des séquences et optimisation vers la performance visée. La mise en service se termine par le transfert formel à l’exploitation, qui exige la formation complète des opérateurs, la remise de la documentation (plans conformes à l’exécution, manuels d’exploitation, instructions de maintenance), la disponibilité des pièces de rechange et le respect des critères d’acceptation convenus. Les périodes de support après mise en service (en général de 30 à 90 jours) permettent à l’intégrateur de résoudre les problèmes qui n’apparaissent que dans les conditions réelles de production.

La colonne vertébrale de la validation : FAT, SAT, SIT et mise en service

Les étapes de validation entre la fin de l’ingénierie et le début de la production stable constituent la discipline qui définit la gestion de projets d’automatisation. Leur ordre est impératif et ne peut pas être raccourci : le matériel et le logiciel doivent d’abord être validés dans un environnement contrôlé (FAT), puis vérifiés dans l’environnement installé (SAT), puis intégrés avec les sous-systèmes voisins (SIT), et enfin démontrés dans les conditions réelles de procédé (mise en service). Chaque étape a des objectifs distincts, des critères d’acceptation distincts et une économie radicalement différente en matière de détection et de correction des défauts.

FAT : détecter les défauts au point le moins coûteux

L’essai d’acceptation en usine se déroule dans les locaux du fournisseur, en présence du client ou d’un inspecteur indépendant. Le système de contrôle-commande complet, ou un sous-ensemble fonctionnellement complet, est monté sur le banc d’essai du fournisseur et testé face à un environnement d’usine simulé avec des simulateurs d’E/S, une stimulation de l’HMI et des scénarios d’essai fonctionnel dérivés de la FDS. Le périmètre type du FAT couvre la vérification des E/S et le contrôle des boucles (chaque canal d’entrée et de sortie fonctionne et est correctement affecté), les essais de logique de commande et de fonctions (verrouillages, permissifs, alarmes, séquences validés face aux P&ID et à la spécification fonctionnelle), l’inspection du matériel et du câblage (dimensions des armoires, repérage des conducteurs, mise à la terre, montage des composants), les contrôles d’étalonnage et d’instruments et la validation de cybersécurité pour les systèmes connectés au réseau. Un FAT correctement mené dure en général de un à cinq jours dans les locaux du fournisseur, selon la complexité du système. La raison économique d’un FAT rigoureux est claire : corriger un défaut en usine coûte en général plusieurs ordres de grandeur de moins que sur le terrain, car la correction en usine n’affecte pas l’échéancier de l’usine, n’engendre pas de coûts logistiques de site, n’interrompt pas l’exploitation et n’exige pas de remobiliser les équipes.

SAT : vérifier l’installation réelle et l’intégration

L’essai d’acceptation sur site se déroule après l’installation dans les locaux du client. Il confirme que l’installation est conforme aux plans, que les E/S physiques sont correctement raccordées aux instruments et actionneurs dans l’usine réelle, que l’intégration avec les systèmes d’usine existants (procédés amont et aval, interfaces MES, ERP) fonctionne comme conçu et que les essais fonctionnels de bout en bout réussissent dans les conditions réelles d’installation. Le SAT révèle souvent des problèmes que le FAT n’a pas pu capter : instruments mal câblés, configurations erronées des équipements de terrain, écarts d’intégration avec les systèmes hérités, perturbations électromagnétiques dues aux installations voisines. Pour les installations SCADA et de procédé continu, le SAT comporte en général un essai de stabilité prolongé d’une à deux semaines pour démontrer que le système fonctionne en continu sans incident majeur. L’approbation du SAT est le jalon vers la mise en service.

SIT : intégrer plusieurs sous-systèmes

Les installations industrielles modernes reposent rarement sur une seule plateforme d’automatisation. Une installation de procédé type intègre plusieurs PLC, automates DCS, systèmes de sécurité, systèmes de détection incendie et gaz, unités packagées, centres de commande de moteurs, variateurs de fréquence, analyseurs, systèmes de protection électrique, historians, systèmes de gestion d’actifs et postes opérateurs, souvent de fournisseurs différents. Chaque sous-système peut passer le FAT et le SAT séparément, mais dès que les systèmes commencent à échanger des données de procédé réelles, des problèmes d’intégration surgissent souvent. L’essai d’intégration sur site (SIT), formellement introduit comme étape standard dans l’IEC 62381:2024, teste tous les sous-systèmes d’automatisation agissant ensemble comme une seule solution de contrôle-commande de procédé. Le SIT est la réponse adaptée à la complexité multifournisseur que les FAT et SAT individuels ne peuvent pas traiter.

Mise en service : démontrer l’aptitude à la production

La mise en service transfère le système validé vers la production en marche. La mise en service à froid vérifie le système sans matière de procédé ou avec des simulants inoffensifs : les pompes tournent, les vannes manœuvrent, les séquences s’exécutent, les alarmes signalent, mais aucun produit n’est en jeu. La mise en service à chaud introduit progressivement de la matière de procédé réelle, règle les boucles de régulation (paramètres PID, configurations en cascade, anticipation) et optimise les séquences (recettes de lot, procédures de démarrage et d’arrêt) vers la performance visée. La mise en service est le moment où la qualité cumulée de l’URS, de la FDS, de l’ingénierie, du FAT et du SAT devient visible : un projet qui a bien mené les phases antérieures est mis en service en quelques jours ou semaines, tandis qu’un projet qui a sauté ou raccourci des phases antérieures peut passer des mois en mise en service à résoudre des problèmes qui auraient dû être détectés plus tôt.

Coordination multidisciplinaire dans les projets d’automatisation

Les projets d’automatisation sont multidisciplinaires par nature d’une manière que ne sont pas les projets de fabrication ordinaires, un domaine où les principes du lean management appliqué à la gestion de projet aident. Un projet d’automatisation de taille moyenne type mobilise au moins cinq disciplines d’ingénierie distinctes travaillant en parallèle, souvent d’entreprises différentes, qui doivent toutes converger vers les mêmes dates d’installation et de mise en service. Coordonner les transferts entre ces disciplines absorbe l’essentiel de l’attention du chef de projet d’automatisation, et réduire les frictions aux transferts est le plus grand levier sur la durée totale du projet.

Ingénierie mécanique et construction

Les prestataires mécaniques installent l’infrastructure physique dont dépend l’automatisation : tuyauteries, vannes, actionneurs, supports de moteurs, supports d’instruments, chemins de câbles. Leur travail précède l’installation électrique et de contrôle-commande, et les retards de la construction mécanique se propagent à chaque discipline en aval. Le périmètre mécanique comprend aussi la fourniture de l’air et de l’hydraulique dont ont besoin les instruments et actionneurs, ce qui doit être coordonné avec la sélection et l’installation des instruments pour éviter les écarts à la mise en service.

Ingénierie électrique et installation

Les prestataires électriques installent la distribution d’énergie, les centres de commande de moteurs, le cheminement des câbles, le câblage des armoires et les raccordements des équipements de terrain. Leur séquence suit la construction mécanique et précède la mise en service du système de contrôle-commande. Les prestataires électriques sont en général aussi responsables du schéma de mise à la terre et de liaison équipotentielle, décisif à la fois pour la sécurité (protection électrique) et pour la fiabilité du système de contrôle-commande (suppression des perturbations sur les câbles de signaux). La coordination entre prestataires électriques et intégrateurs de contrôle-commande autour des listes de câbles, de l’agencement des armoires et des listes de bornes est une source de friction permanente dans le projet, que les chefs de projet d’automatisation expérimentés anticipent dans leur planification.

Ingénierie et intégration du contrôle-commande

L’intégrateur de contrôle-commande est responsable de la sélection et de la programmation du matériel PLC, de la configuration SCADA et du développement des vues, de la conception et de la validation du système de sécurité, de l’architecture réseau et de la configuration de l’historian et des rapports. C’est la discipline qui livre le plus directement la fonctionnalité d’automatisation qu’utilisera l’exploitation. Les intégrateurs de contrôle-commande sous-traitent souvent des éléments précis (programmation du système de sécurité, évaluation de cybersécurité, conception réseau) à des sociétés spécialisées, ce qui ajoute une couche de coordination supplémentaire que le chef de projet doit gérer.

Ingénierie des réseaux IT et OT

Les systèmes d’automatisation modernes sont intégrés au réseau et exigent leur propre infrastructure réseau, séparée de l’IT d’entreprise, avec des interfaces définies là où elles se recoupent. L’ingénierie des réseaux IT/OT couvre l’architecture du réseau de contrôle-commande (en général des variantes d’Ethernet industriel), la segmentation entre la zone de contrôle-commande et la zone d’entreprise, les mesures de cybersécurité conformes à l’IEC 62443, les politiques d’accès distant et l’intégration avec l’historian d’usine et les systèmes MES. Les ingénieurs IT/OT restaient historiquement en dehors des projets d’automatisation et étaient impliqués tard, mais les projets modernes gagnent à les associer dès l’URS, car les décisions réseau influencent la conception physique des armoires et le cheminement des câbles.

Ingénierie de procédé et exploitation

Les ingénieurs de procédé fournissent la philosophie de commande que mettent en œuvre le PLC et le SCADA : quelles boucles nécessitent quelle stratégie de régulation, quels verrouillages protègent contre quels modes de défaillance, quelles alarmes les opérateurs doivent voir. L’exploitation apporte le savoir opérationnel qui devient le contenu de l’URS : comment l’usine fonctionne réellement, ce dont les opérateurs ont besoin sur leurs écrans, quelles séquences requièrent quelles options, quelles informations aident au dépannage à trois heures du matin. Les projets d’automatisation qui maintiennent l’ingénierie de procédé et l’exploitation impliquées de l’URS à la mise en service surpassent systématiquement les projets qui les traitent comme des parties prenantes consultées et non comme des participants actifs du projet.

Pièges fréquents des projets d’automatisation

Cinq schémas d’échec se répètent d’un projet d’automatisation à l’autre, quel que soit le secteur, et chacun peut être prévenu par des contre-mesures concrètes. Nommer ces schémas permet de les reconnaître plus tôt dans les projets futurs, quand ils peuvent encore être interceptés pour une fraction du coût de leur résolution à la mise en service.

URS insuffisamment spécifiée transmise à l’ingénierie

Le premier schéma consiste à traiter l’URS comme une formalité précoce plutôt que comme le socle sur lequel repose tout le projet. L’URS est rédigée à la hâte pour libérer l’ingénierie, les ambiguïtés restent dans le document en supposant qu’elles seront levées plus tard, et l’ingénierie avance face à un ensemble d’exigences mal défini. Les conséquences apparaissent au SAT et à la mise en service : l’exploitation découvre que le système ne fait pas quelque chose qu’elle tenait pour acquis, ou fait quelque chose qu’elle n’a jamais voulu, et la correction exige une reconception qu’une URS solide aurait évitée. La contre-mesure consiste à investir le temps calendaire dans une URS rigoureuse, avec approbation explicite des parties prenantes et critères d’acceptation définis avant le début de l’ingénierie, même si cela semble retarder le projet.

FAT raccourci ou sauté

Le deuxième schéma consiste à traiter le FAT comme une étape optionnelle que l’on peut raccourcir quand l’échéancier est sous pression. Le fournisseur a terminé le logiciel et le matériel est monté, mais le client décide que le FAT est inutile parce que le fournisseur teste bien en interne, ou que le FAT peut se réduire à une démonstration plutôt qu’à un essai fonctionnel complet. Les conséquences apparaissent au SAT et à la mise en service, où chaque défaut que le FAT aurait intercepté coûte désormais dix à cent fois plus à corriger. La contre-mesure consiste à traiter le FAT comme non négociable, quelle que soit la pression sur les délais, et à structurer le périmètre du FAT de façon assez concrète pour qu’une démonstration ne puisse pas passer pour un essai.

Lacunes de coordination multifournisseur sans SIT

Le troisième schéma consiste à supposer que les FAT et SAT individuels des fournisseurs suffisent lorsque plusieurs sous-systèmes doivent fonctionner ensemble. Le système de chaque fournisseur passe ses propres essais, mais les interfaces entre systèmes n’ont pas été validées conjointement, et les problèmes d’intégration surgissent durant la mise en service, quand leur résolution est la plus coûteuse. La contre-mesure consiste à planifier un essai d’intégration sur site explicite lorsque le projet comporte plusieurs sous-systèmes de fournisseurs différents, et à définir le périmètre du SIT dès l’URS, afin que les fournisseurs sachent qu’ils sont contractuellement tenus de participer à des essais intégrés et non seulement de valider leur propre sous-système.

Retards des disciplines voisines qui débordent sur l’automatisation

Le quatrième schéma consiste à traiter la durée du projet d’automatisation comme si elle était indépendante des autres disciplines du site. La construction mécanique prend du retard, l’installation électrique prend du retard, et l’équipe d’automatisation arrive pour commencer le SAT pour découvrir que l’usine n’est pas prête à l’accueillir. Les échéanciers de l’équipe d’automatisation ne peuvent en général pas glisser dans le même sens, car les fenêtres de mise en service sont liées à des arrêts d’usine ou à des fenêtres de démarrage fixées longtemps à l’avance. La contre-mesure consiste à intégrer explicitement les échéanciers du projet d’automatisation avec les échéanciers mécanique et électrique, avec des jalons de préparation de chaque discipline pour les activités d’automatisation et des déclencheurs d’escalade lorsqu’une discipline glisse au-delà de la marge.

Validation de sécurité et de cybersécurité reportée

Le cinquième schéma consiste à traiter les essais de sécurité fonctionnelle et la validation de cybersécurité comme des activités de cérémonie en fin de parcours plutôt que comme des flux de travail continus tout au long du projet. Les fonctions de sécurité exigent une validation face à la spécification des exigences de sécurité sur tout le cycle de vie, de la conception au FAT et au SAT jusqu’à la mise en service, et la cybersécurité conforme à l’IEC 62443 exige de même des mesures dès la conception plutôt qu’un audit en fin de projet. La contre-mesure consiste à définir des flux de travail de sécurité et de cybersécurité avec des livrables explicites par phase, à les doter de ressources séparées des essais fonctionnels et à traiter l’acceptation de sécurité et de cybersécurité comme des jalons propres plutôt que comme des points d’une liste d’acceptation générale.

Sécurité et conformité dans les projets d’automatisation

Les projets d’automatisation opèrent dans des cadres réglementaires et normatifs que les projets de fabrication génériques rencontrent rarement avec la même intensité. La sécurité fonctionnelle, la cybersécurité, les réglementations sectorielles et les normes industrielles imposent toutes des exigences qui doivent être intégrées à la structure du projet dès l’URS, non ajoutées à la mise en service. Un manquement de conformité au transfert est au mieux coûteux et au pire bloque l’exploitation, et la discipline consistant à intégrer la conformité au flux du projet sépare les chefs de projet d’automatisation qui livrent à temps de ceux qui passent le dernier mois à chercher des preuves pour l’audit.

Sécurité fonctionnelle selon l’IEC 61511 et l’IEC 61508

Les systèmes de sécurité dans l’industrie de procédé suivent l’IEC 61511 (avec l’IEC 61508 comme norme sous-jacente). Les exigences du cycle de vie comprennent l’analyse des dangers et des risques, l’affectation des fonctions de sécurité à des fonctions instrumentées de sécurité (SIF) avec des niveaux d’intégrité de sécurité (SIL), la spécification des exigences de sécurité, la conception et l’ingénierie avec vérification du SIL, la validation lors de l’installation et de la mise en service, et les procédures d’exploitation et de maintenance. La sécurité ne peut pas être ajoutée à la mise en service ; elle doit être présente à chaque phase. Les projets d’automatisation qui traitent la sécurité comme un flux de travail propre dès l’URS produisent des preuves prêtes pour l’audit comme résultat naturel du projet, tandis que les projets qui traitent la sécurité comme une activité d’acceptation finale découvrent en général tard que des lacunes de documentation ou des problèmes de conception exigent des reprises.

Cybersécurité selon l’IEC 62443

Les systèmes d’automatisation et de contrôle-commande industriels font face à des menaces de cybersécurité que les cadres de sécurité IT ne couvrent pas entièrement. L’IEC 62443 définit les exigences de cybersécurité pour l’automatisation industrielle, dont la segmentation réseau entre les zones IT et OT, l’accès distant sécurisé, la gestion des correctifs des systèmes de contrôle-commande, la journalisation des événements de sécurité et la gestion des vulnérabilités. Les exigences de cybersécurité doivent être définies durant l’URS et déclinées dans la FDS, la DDS et l’ingénierie. Ajouter la cybersécurité à la mise en service est coûteux et donne rarement des résultats satisfaisants, car les décisions fondamentales d’architecture sont déjà prises.

Réglementations sectorielles

Différents secteurs industriels ajoutent aux projets d’automatisation des exigences de conformité spécifiques. Les projets pharmaceutiques et de sciences de la vie suivent l’Annexe 15 des GMP de l’UE, qui reconnaît expressément le rôle du FAT et du SAT dans la qualification et exige des preuves documentées de l’instrumentation critique, de l’étalonnage et de la vérification du procédé. La FDA 21 CFR Part 11 s’applique aux enregistrements et signatures électroniques dans les sciences de la vie. Les projets agroalimentaires suivent les principes HACCP avec des normes sectorielles de conception hygiénique et de traçabilité. Les projets d’énergie et de services publics suivent la NERC CIP pour la cybersécurité du réseau. Les projets d’industrie générale exigent la preuve du marquage CE et les normes ISO pertinentes de sécurité, de performance et de spécifications techniques. Les exigences du secteur doivent être identifiées durant l’URS, et l’échéancier du projet doit tenir compte des activités d’audit et de documentation qu’elles imposent.

Gérer plusieurs projets d’automatisation au niveau du portefeuille

Une société d’ingénierie qui livre des projets d’automatisation, ou un industriel menant plusieurs initiatives d’automatisation simultanées, a rarement un seul projet en cours. Plus typiquement, le portefeuille comprend plusieurs projets à des phases différentes qui se disputent les mêmes talents d’ingénierie, les mêmes moyens d’essai, la même capacité d’intégration et les mêmes fenêtres de mise en service. La vue de portefeuille est l’endroit où la gestion de projets d’automatisation passe d’une discipline de projet à une capacité organisationnelle, et où les plus grands gains de débit global sont disponibles.

Le tableau de bord de portefeuille des projets d’automatisation

Un tableau de bord de portefeuille de projets d’automatisation présente tous les projets actifs classés par phase (URS, FDS, ingénierie, FAT, SAT, mise en service), avec une visibilité sur les projets qui approchent des revues de jalon, ceux qui sont bloqués et le nombre de projets à chaque phase. Le tableau de bord révèle des schémas que les vues de projet isolées masquent : goulots d’étranglement systématiques dans la planification du FAT avec le même intégrateur, fenêtres de mise en service qui se concentrent dans des plages de calendrier étroites, concurrence de ressources sur des compétences spécialisées comme la programmation des systèmes de sécurité. La reconnaissance de schémas au niveau du portefeuille alimente l’amélioration systémique plutôt que la lutte réactive contre les incendies projet par projet.

Concurrence de ressources sur les compétences spécialisées

Les projets d’automatisation dépendent de compétences spécialisées souvent rares : programmeurs de systèmes de sécurité, spécialistes de cybersécurité, architectes réseau, experts de certaines plateformes PLC, ingénieurs de mise en service dotés d’expérience sectorielle. Les ressources partagées deviennent la plus grande source de retards non planifiés sur un portefeuille de plusieurs projets. La concurrence de ressources, invisible au niveau du projet, devient visible au niveau du portefeuille, où le même spécialiste apparaissant simultanément dans plusieurs échéanciers de projet met au jour la double réservation que les chefs de projet individuels ne peuvent pas voir. Une gestion de portefeuille efficace détecte tôt ces goulots d’étranglement et, soit ajoute de la capacité, soit ordonnance les projets pour réduire la concurrence, soit accepte les retards comme des décisions de portefeuille visibles.

Standardisation entre projets

Les portefeuilles matures de projets d’automatisation standardisent les éléments récurrents : modèles d’URS par type de projet, structures de FDS, formats de scénarios d’essai FAT, critères d’acceptation SAT, listes de contrôle de mise en service, modèles de documentation de sécurité, procédures d’évaluation de cybersécurité. La standardisation évite de réinventer les éléments routiniers à chaque projet et libère l’attention d’ingénierie pour les parties qui diffèrent vraiment. La standardisation permet aussi l’apprentissage entre projets : un schéma de défaut mis au jour au FAT d’un projet met à jour les modèles, de sorte que les projets suivants interceptent plus tôt la même classe de défauts. Les sociétés d’ingénierie dotées d’une standardisation mature livrent des projets plus vite et avec moins de variabilité que les sociétés où chaque projet réinvente sa propre approche.

Planification de capacité et décisions d’offre au niveau du portefeuille

La visibilité au niveau du portefeuille sur la charge actuelle des projets et sur la disponibilité prévue des ressources soutient les décisions commerciales que les sociétés d’ingénierie prennent en continu : à quels appels d’offres répondre, quelles dates de livraison s’engager à tenir, quand recruter, quand dire non à certaines opportunités. Les sociétés sans données de capacité au niveau du portefeuille se surchargent en général dans les phases optimistes et se retiennent dans les phases prudentes, la variabilité de livraison qui en résulte dégradant les relations clients et la fidélisation du personnel. Les sociétés dotées de données de portefeuille peuvent prendre des décisions d’offre à partir de la capacité de livraison réelle plutôt que de l’optimisme sur ce que l’équipe peut absorber.

Étude de cas A : Smart Automation, exécution disciplinée du portefeuille

Smart Automation est une société d’ingénierie d’Olsztyn, en Pologne, active dans l’automatisation industrielle depuis 2009. La société conçoit et livre des systèmes d’automatisation complets, des concepts de machines et analyses de faisabilité à la programmation des systèmes de contrôle-commande et aux systèmes de vision artificielle, en passant par l’automatisation robotisée de procédés et la construction de machines spécialisées. L’expérience de l’équipe totalise plus de 300 ans en automatisation, robotique et mécatronique. La société a mené à bien plus de 1 000 projets pour des clients comme IKEA, Michelin, Siemens Energy, Unilever et Danone, ce qui signifie en pratique plusieurs dizaines de projets simultanés à tout moment, différents en périmètre, en complexité et en implantation.

Le point de départ avant l’adoption de FlexiProject était familier aux sociétés d’ingénierie : les budgets étaient gérés dans des solutions autour du système ERP, parce que c’est là que résident les factures, les paiements et les coûts, mais chaque chef de projet avait développé une approche personnelle du contrôle financier. Les outils de planification d’échéancier, de suivi des risques et de planification des ressources faisaient pour l’essentiel défaut. Il n’y avait pas de vision complète d’un seul projet, encore moins de tout le portefeuille. La société a décidé de chercher un système de gestion de projet dédié réunissant échéanciers, budgets, risques et ressources en un seul endroit et devenant la source unique d’information sur les projets.

L’adoption a couvert toute l’organisation. En trois mois, les 51 projets actifs de complexité variée ont été basculés dans FlexiProject. Aujourd’hui, tous les collaborateurs et les sous-traitants clés utilisent le système, soit 37 personnes au total, ce qu’un pool de licences flexible a rendu réalisable. Plus important encore : la société a compris l’adoption comme une occasion de bâtir un standard commun de gestion de projet, et non seulement de remplacer un outil. Chaque projet commence désormais de la même façon : par une charte de projet qui définit objectifs, périmètre et responsabilités, et par un modèle de phases qui ordonne le travail du concept au transfert. Les échéanciers sont créés à partir d’un modèle commun avec dépendances de Gantt et jalons, et chaque planning est enregistré comme référence de base : un point de référence approuvé face auquel se mesurent les écarts de délai et de coût.

Les données de budget devaient rester cohérentes avec le système ERP, aussi FlexiProject a-t-il été intégré à l’ERP de sorte que l’information de coût circule entre les systèmes sans double saisie. Au-delà des projets, la structure flexible a permis de refléter le processus d’offre ainsi que le service de garantie et de post-garantie. Deux facteurs ont porté l’adoption. D’abord, le directeur général a agi comme sponsor actif du projet, exigeant de façon constante que toute l’information de projet vive dans un seul système et attendant des mises à jour régulières de chaque chef de projet. Ensuite, la barrière d’entrée était basse : construire des échéanciers et des budgets était assez intuitif pour que chaque chef de projet, quelle que soit son expérience, puisse commencer la formation en saisissant un vrai projet à lui plutôt qu’en s’exerçant sur des exemples artificiels. Les résultats se voient dans les décisions : écarts de budget avec prévision jusqu’à l’achèvement, utilisation des ressources comme donnée d’entrée pour les décisions d’offre et les plans de recrutement, revues de projet toutes les deux semaines pour les projets actifs et mensuelles pour les projets en phase de planification, le tout à partir des données du système plutôt que de présentations élaborées à la main.

Étude de cas B : la crise d’automatisation du Model 3 de Tesla, 2017-2018

La montée en cadence de production du Model 3 de Tesla entre 2017 et 2018 est l’un des échecs de projet d’automatisation les mieux documentés publiquement de l’histoire industrielle, insolite par la disposition d’Elon Musk à l’admettre avec ses propres mots. Le Model 3 a été annoncé en 2016 comme le premier véhicule de grande diffusion de Tesla, à un prix cible de 35 000 USD, et dans les 24 heures suivant le lancement, 115 000 personnes avaient passé des réservations. Tesla s’est fixé l’objectif ambitieux de produire 5 000 Model 3 par semaine d’ici la fin 2017 et a suivi une approche que Musk décrira plus tard comme « tout automatiser », pariant qu’une automatisation extensive permettrait le volume nécessaire pour absorber le carnet de précommandes.

Le résultat a été ce que Musk lui-même a appelé « l’enfer de la production ». Tesla a largement manqué l’objectif de fin 2017 et a produit 2 425 Model 3 sur tout le quatrième trimestre 2017 (contre un objectif de 5 000 par semaine). L’objectif révisé pour la fin du premier trimestre 2018, de 2 500 par semaine, a lui aussi été manqué, Tesla atteignant 2 020 lors de la dernière semaine du premier trimestre. Tant l’assemblage des modules de batterie à la Gigafactory que la ligne d’assemblage final à Fremont avaient des conceptions d’automatisation qui se sont révélées peu fiables au volume de production. Les analystes de Bernstein ont soutenu publiquement que la surautomatisation gravait les erreurs de Tesla dans la ligne de production et coûtait plus qu’elle ne rapportait. Le 13 avril 2018, Musk a admis publiquement sur Twitter : « Oui, l’excès d’automatisation chez Tesla a été une erreur. Pour être précis, mon erreur. Les humains sont sous-estimés. » Dans un entretien à CBS, il a décrit le démantèlement d’un « réseau fou et complexe de convoyeurs » qui ne fonctionnait pas, et Tesla a fini par ramener des parties de la ligne d’assemblage à une opération manuelle, y compris la fameuse ligne d’assemblage provisoire sous « tente » à Fremont, qui a ajouté de la capacité par le travail manuel plutôt que par davantage d’automatisation.

Trois leçons se transposent directement à tout projet d’automatisation. Premièrement, l’ambition d’automatiser sans validation pilote multiplie le risque au lieu de le réduire : la décision de Tesla de déployer une nouvelle automatisation à l’échelle de la production avant de la valider à un volume pilote a multiplié la difficulté de chaque cycle ultérieur de résolution de problèmes, alors qu’une montée en cadence progressive aurait mis au jour les problèmes d’automatisation à moindre coût. Deuxièmement, surautomatiser des étapes de sous-assemblage qui exigent de l’adaptabilité produit de moins bons résultats que les alternatives semi-automatisées où les humains prennent en charge la variation et les machines le travail répétable : c’est un principe connu de la pratique de fabrication japonaise que Tesla a de fait redécouvert sous la pression de production. Troisièmement, les engagements d’échéancier de projet qui supposent que la technologie fonctionnera comme prévu, sans marge suffisante pour mettre au jour les problèmes d’automatisation, engendrent une pression qui rend la résolution disciplinée de problèmes plus difficile plutôt que plus facile. Tesla a fini par atteindre l’objectif de 5 000 par semaine à la fin juin 2018 et a plus que doublé sa production totale de 2017, mais le prix de l’avoir obtenu par une crise plutôt que par une montée en cadence disciplinée a été considérable.

Comment FlexiProject soutient les projets d’automatisation

FlexiProject soutient le niveau d’exécution de la gestion de projets d’automatisation avec la visibilité de portefeuille, la gestion d’échéancier, le suivi des risques, les revues structurées et les modèles standardisés. La coordination multidisciplinaire des projets d’automatisation, en particulier le travail d’harmonisation des fonctions de mécanique, d’électricité, de contrôle-commande, d’IT/OT et d’ingénierie de procédé, reste de la responsabilité de l’organisation. FlexiProject apporte l’infrastructure opérationnelle qui rend gérable l’exécution disciplinée de projets d’automatisation à grande échelle, non un substitut à la collaboration d’ingénierie dont dépend le succès d’un projet d’automatisation.

Vue de portefeuille pour les projets d’automatisation simultanés

FlexiProject offre un tableau de bord de portefeuille qui présente tous les projets d’automatisation actifs dans une seule vue, classés par phase (URS, FDS, ingénierie, FAT, SAT, mise en service) et par client ou unité opérationnelle, avec une visibilité sur les projets qui approchent des revues de jalon et ceux qui sont bloqués. La vue de portefeuille met en lumière des schémas que les vues de projet isolées masquent, comme des fenêtres de mise en service qui se concentrent dans des plages de calendrier étroites, la concurrence de ressources sur des compétences spécialisées et des retards systématiques dans la planification du FAT avec certains intégrateurs. Les comités de pilotage qui prennent des décisions au niveau du portefeuille travaillent à partir de la même vue de portefeuille, plutôt que de rapprocher des rapports de projet distincts.

Échéancier avec diagramme de Gantt, liste de tâches et kanban

L’échéancier dans FlexiProject combine une vue diagramme de Gantt pour le suivi des jalons et la visualisation des dépendances, une vue liste de tâches pour le travail d’exécution détaillé et une vue kanban pour la discipline de flux à l’intérieur des phases. Les projets d’automatisation tirent parti de la combinaison : le diagramme de Gantt gère la structure au niveau des phases avec les dépendances de l’URS à la mise en service et les jalons de revue, les listes de tâches gèrent le travail détaillé d’ingénierie et d’essai à l’intérieur des phases, et le kanban suit le flux des livrables concrets à travers la revue et l’approbation. Les icônes d’avertissement sur les tâches d’échéancier signalent les problèmes de budget ou de risque sans exiger de rapports séparés.

Registre des risques, relié aux phases du projet

Le registre des risques dans FlexiProject suit les risques propres à l’automatisation avec des responsables, des plans de réduction et un rythme de revue. Les risques propres à chaque phase (disponibilité des composants à long délai d’approvisionnement durant l’ingénierie, préparation du fournisseur pour le FAT, préparation du site pour le SAT, disponibilité de l’usine pour la mise en service, validation du système de sécurité, évaluation de cybersécurité) sont reliés aux jalons de phase pertinents et revus au jalon correspondant. Le lien entre risques, tâches et échéancier fait qu’un risque qui se matérialise se répercute visiblement sur le délai associé, au lieu de rester dans un registre à part que personne ne consulte au moment des décisions de délai.

Revues de projet comme revues de jalon

Les revues de projet dans FlexiProject peuvent être structurées comme des revues de jalon formelles des projets d’automatisation, avec des critères définis, une présentation structurée des preuves et des décisions formelles de poursuite ou d’arrêt consignées au compte rendu du projet. Le rythme de revue est planifié (en général à la fin de chaque phase de projet et à chaque transition FAT/SAT/mise en service), et les résultats des revues alimentent les modèles standardisés des projets suivants. Les critères de jalon configurés dans les modèles s’appliquent de façon cohérente entre projets du même type, de sorte que le jalon d’approbation du FAT d’un projet utilise la même structure de critères que le jalon d’approbation du FAT d’un autre.

Modèles standardisés pour les projets d’automatisation

FlexiProject propose des modèles standardisés pour la structure récurrente des projets d’automatisation, avec le modèle en six phases, la colonne vertébrale de validation FAT-SAT-mise en service, les livrables standard par phase et des critères de jalon standard adaptés à l’automatisation. Les sociétés d’ingénierie peuvent étendre les modèles selon les particularités du type de projet (greenfield, modernisation brownfield, extension de capacité, mise à niveau de sécurité) sans renoncer à la structure de base. La gestion de projets d’automatisation fondée sur des modèles agit comme l’équivalent numérique de la pratique d’ingénierie standardisée : elle évite de réinventer les éléments routiniers du projet et libère l’attention d’ingénierie pour les parties de chaque projet qui diffèrent vraiment.

Ce que FlexiProject ne fait pas

FlexiProject ne réalise pas l’ingénierie (c’est le travail de l’intégrateur de contrôle-commande), ne réalise ni le FAT ni le SAT (ils exigent des bancs d’essai et de l’instrumentation), ne qualifie pas les fournisseurs (cela exige des processus d’achats et de qualité) et ne remplace pas la discipline consistant à faire respecter les critères de jalon (cela exige l’engagement de la direction). Il apporte la visibilité, la structure et la traçabilité qui rendent gérable l’exécution disciplinée de projets d’automatisation sur un portefeuille, mais la discipline elle-même est organisationnelle.

Foire aux questions

En quoi la gestion de projets d’automatisation diffère-t-elle de la gestion de projet générale ?

Les principes généraux de gestion de projet s’appliquent aux projets d’automatisation, mais ces derniers présentent des traits propres que les approches générales ne couvrent pas entièrement : une colonne vertébrale de validation séquentielle et impérative (FAT avant SAT avant mise en service), une complexité multidisciplinaire inhérente couvrant mécanique, électricité, logiciel de contrôle-commande, IT/OT et ingénierie de procédé, des exigences de sécurité et de conformité à poids réglementaire, et une dépendance à plusieurs fournisseurs externes dont les retards se propagent de façon imprévisible. Les chefs de projet d’automatisation ont en général une formation d’ingénieur et une expérience sectorielle spécifique, car le contenu technique des décisions influence les résultats du projet à un niveau que la gestion de projet générale ne peut pas remplacer.

Combien de temps dure un projet d’automatisation type ?

Cela dépend du périmètre, de la complexité et du secteur. Une installation greenfield simple avec une intégration limitée peut s’achever en six à neuf mois. Une modernisation brownfield type avec intégration aux systèmes d’usine existants dure en général de douze à dix-huit mois. Les grands projets d’investissement avec une technologie inédite ou des éléments critiques de sécurité peuvent durer de deux à trois ans. Le plus grand facteur isolé d’échéancier n’est souvent pas la complexité d’ingénierie mais la complexité de coordination : les projets avec de nombreux fournisseurs et disciplines durent plus longtemps que les projets avec moins de participants, même si le travail technique est similaire.

À qui appartient le projet d’automatisation ?

Un chef de projet d’automatisation est responsable de l’échéancier, de la coordination, des revues de jalon et de l’alignement entre disciplines, mais le travail est multidisciplinaire par nature et aucune fonction ne le contrôle seule. Les prestataires mécaniques sont responsables de l’infrastructure physique, les prestataires électriques de l’alimentation et du câblage, l’intégrateur de contrôle-commande de la livraison du PLC et du SCADA, les ingénieurs IT/OT de l’infrastructure réseau, les ingénieurs de procédé de la philosophie de commande, et l’exploitation des exigences que le système doit satisfaire. Le chef de projet d’automatisation est le coordinateur et l’intégrateur entre ces fonctions. Le soutien de la direction générale est indispensable, car les décisions de jalon ont des implications commerciales et de sécurité qui dépassent l’autorité du chef de projet.

Quelle est la différence entre le FAT et le SAT ?

Le FAT (essai d’acceptation en usine) se déroule dans les locaux du fournisseur ou de l’intégrateur avant l’expédition vers le site, avec des entrées et sorties simulées, pour valider le matériel et le logiciel dans un environnement contrôlé. Le SAT (essai d’acceptation sur site) se déroule après l’installation dans les locaux du client et vérifie que l’installation est conforme aux plans, que les E/S physiques sont correctement raccordées à des instruments et actionneurs réels et que l’intégration avec les systèmes d’usine existants fonctionne. Le FAT intercepte les défauts au point le moins coûteux du cycle de vie ; le SAT intercepte les problèmes qui n’apparaissent que dans l’environnement réel d’installation. Aucun ne peut remplacer l’autre, et les deux sont en général nécessaires.

Le FAT et le SAT sont-ils obligatoires par la loi ?

Cela dépend du secteur. Les projets pharmaceutiques et de sciences de la vie exigent le FAT et le SAT de fait selon l’Annexe 15 des GMP de l’UE, qui reconnaît expressément leur rôle dans la qualification. Pour les installations d’industrie générale, le marquage CE et les normes ISO pertinentes exigent la preuve que l’installation satisfait les spécifications de sécurité, de performance et techniques, et le FAT et le SAT sont les mécanismes standard pour apporter cette preuve. Même là où ils ne sont pas strictement obligatoires par la loi, le FAT et le SAT sont une pratique courante dans la plupart des secteurs industriels, car la raison économique d’intercepter les défauts au point le plus précoce possible est bien documentée.

Les projets d’automatisation peuvent-ils suivre des méthodes agiles ?

Les projets d’automatisation ont des dépendances physiques qui limitent l’applicabilité des méthodes purement agiles : le matériel demande un délai d’approvisionnement, la mise en service exige des fenêtres de disponibilité de l’usine, la validation de sécurité suit des séquences réglementaires qui ne peuvent pas être itérées. Des éléments de la pensée agile s’ajustent bien, en particulier le raffinement itératif de l’URS avec les parties prenantes avant le gel de conception et le débogage itératif durant le FAT et la mise en service. Mais la structure de phases de l’URS à la mise en service est une colonne vertébrale en cascade, car les contraintes physiques et réglementaires l’imposent, et les tentatives d’appliquer des méthodes purement agiles aux projets d’automatisation donnent en général de moins bons résultats que l’approche disciplinée à phases et jalons.

La gestion de projets d’automatisation est la discipline qui consiste à livrer des projets d’automatisation industrielle depuis la spécification des besoins utilisateur, en passant par l’ingénierie, le FAT, le SAT et la mise en service, jusqu’à la production stable, distincte de la gestion de projets de fabrication générique par sa colonne vertébrale de validation séquentielle et impérative, sa complexité multidisciplinaire inhérente, l’intensité de la sécurité et de la conformité et la dépendance à la coordination de plusieurs fournisseurs. La structure en six phases de l’URS à la mise en service fournit le cadre, et la colonne vertébrale de validation FAT-SAT-SIT-mise en service fournit la discipline qui la définit, les défauts détectés au FAT coûtant un ordre de grandeur de moins qu’au SAT et deux ordres de grandeur de moins que durant la mise en service. La coordination multidisciplinaire entre les fonctions de mécanique, d’électricité, de contrôle-commande, d’IT/OT et d’ingénierie de procédé absorbe l’essentiel de l’attention du chef de projet, et réduire la friction aux transferts est le plus grand levier isolé sur la durée totale du projet. Cinq schémas d’échec (URS insuffisamment spécifiée, FAT raccourci, lacunes de coordination multifournisseur sans SIT, retards des disciplines voisines qui débordent, et sécurité et cybersécurité reportées) peuvent être prévenus par des contre-mesures nommées. Les exigences de sécurité et de conformité, dont l’IEC 61511, l’IEC 62443 et les réglementations sectorielles, doivent être intégrées au flux du projet dès l’URS. La visibilité au niveau du portefeuille sur les projets d’automatisation simultanés permet les décisions de ressources, de standardisation et de capacité que les sociétés d’ingénierie prennent en continu. Le cas Smart Automation montre qu’une société d’ingénierie de taille moyenne peut bâtir en quelques mois un standard de projet discipliné autour d’un système commun, tandis que le cas du Model 3 de Tesla montre que l’ambition d’automatiser sans validation pilote ni exécution disciplinée à phases et jalons engendre « l’enfer de la production » à la plus grande échelle possible. FlexiProject soutient le niveau d’exécution de la gestion de projets d’automatisation avec la visibilité de portefeuille, la gestion d’échéancier combinant les vues diagramme de Gantt, liste de tâches et kanban, un registre des risques relié aux phases, des revues structurées comme revues de jalon et des modèles de projet standardisés. La coordination multidisciplinaire d’ingénierie et le respect discipliné des critères de jalon restent des responsabilités organisationnelles. Lorsque le portefeuille de projets d’automatisation d’une société d’ingénierie a dépassé les tableurs et a besoin d’un système qui soutient la discipline entre plusieurs projets simultanés et des équipes multidisciplinaires, trente jours d’accès complet sans carte bancaire sont un moyen pratique de vérifier l’adéquation.