Le démarrage est le moment où tout le monde regarde l'automaticien. Les problèmes qui apparaissent là ne sont presque jamais nés là : ils viennent de tests d'acceptation escamotés. FAT et SAT ne sont pas des formalités de réception — ce sont vos deux filets de sécurité.
Sommaire
FAT et SAT : deux étapes, deux objectifs
Le FAT (Factory Acceptance Test) se déroule en plateforme, avant l'expédition : on vérifie que l'application fait ce qu'elle doit, souvent par simulation des entrées-sorties. Le SAT (Site Acceptance Test) se déroule sur site, après installation : on vérifie que tout ce qui a été validé en usine fonctionne aussi une fois raccordé au procédé réel. Les deux sont au cœur de notre expertise FAT/SAT.
Sauter le FAT pour « gagner du temps » est la fausse bonne idée par excellence : un défaut trouvé en plateforme se corrige en minutes ; le même défaut trouvé au démarrage se paie en heures d'arrêt et en tension d'équipe.
Un défaut détecté en FAT coûte une fraction de ce qu'il coûte au SAT, et une fraction infime de ce qu'il coûte au démarrage. Plus on trouve tôt, moins on paie. C'est la logique qui doit guider tout le plan de tests.
Ce qu'un bon FAT couvre
- Les séquences et logiques fonctionnelles, cas nominaux et cas dégradés
- Les fonctions de sécurité et les interverrouillages (voir sûreté fonctionnelle)
- Les alarmes : déclenchement, acquittement, priorités
- Les vues opérateur et la cohérence de la supervision
- La simulation des I/O pour rejouer des scénarios difficiles à provoquer sur site
Un bon FAT ne se contente pas de dérouler les cas qui marchent : il cherche activement à faire tomber l'application. Ce sont les cas dégradés et les transitions imprévues qui révèlent les vrais défauts de conception.
Ce que le SAT ajoute
Le SAT est le moment de vérité du câblage. C'est là qu'on réalise le loop check : chaque boucle est vérifiée physiquement, du capteur jusqu'à l'écran, du signal de sortie jusqu'à l'actionneur. C'est fastidieux — et c'est précisément ce qui évite les surprises au démarrage.
Considérer que « ça a marché en FAT, donc ça marchera sur site ». Le câblage réel, les échelles d'instruments et les temporisations du procédé réservent toujours des écarts. Le SAT n'est pas une redite du FAT : c'est la confrontation au terrain.
FAT/SAT et migration : un enjeu renforcé
Lors d'une migration DCS, le FAT prend une dimension supplémentaire : il permet de rejouer les recettes et les réglages de l'ancien système sur le nouveau, avant de toucher au procédé. Un FAT sérieux est ce qui rend une bascule à chaud envisageable sans casser la production.
La punch list : le nerf de la guerre
Aucun test ne se termine avec zéro réserve. Ce qui distingue un projet maîtrisé, c'est une punch list structurée : chaque écart est consigné, classé par criticité, affecté à un responsable et suivi jusqu'à sa levée. Sans elle, les réserves se perdent et ressurgissent au pire moment — c'est l'une des erreurs classiques de mise en service.
- Cahiers de tests rédigés et exécutés, avec PV signés
- Fonctions de sécurité testées et tracées
- Loop check complet réalisé sur site
- Punch list à jour, réserves critiques levées
- Documentation de conduite remise aux équipes
Un FAT et un SAT bien menés transforment le démarrage : au lieu d'être un saut dans l'inconnu, il devient la confirmation d'un travail déjà validé. Si vous préparez un démarrage sensible, un diagnostic gratuit permet d'identifier les points à sécuriser en priorité.
