Développer en interne ou utiliser MCSA ?
C'est une question légitime. MOCUS, BDD, minimisation des cut-sets — les algorithmes FTA sont dans la littérature depuis les années 70. Une équipe avec un background safety et des compétences C++ peut construire un moteur d'arbres de défaillances. Cette page expose ce qui motive vraiment la décision : pas les algorithmes, mais tout ce qui se trouve autour.
L'effort n'est pas dans l'implémentation
Les algorithmes sont le plus petit poste de coût. Le vrai goulot d'étranglement se trouve dans l'ISO 26262-8 Clause 11 : la qualification d'outil. Sans cette preuve, l'outil ne peut pas être utilisé dans le safety case.
-
Déterminer le Tool Confidence Level
Dériver TCL1/2/3 du Tool Impact (TI) et de la Tool Error Detection (TD) — plus l'impact est élevé, plus la méthode de qualification est exigeante.
-
Choisir une méthode de qualification
Pour TCL2/3, choisir entre « Increased Confidence from Use », « Validation of the Software Tool », « Development in Accordance with a Safety Standard » ou « Evaluation of the Tool Development Process ».
-
Produire les preuves
Plan de validation, test corpus avec preuves de couverture, preuves de régression, traçabilité exigence-test, cas d'usage documentés et limitations connues.
-
Re-qualifier à chaque modification
Chaque bugfix, feature ou upgrade de compilateur exige au moins une delta-analyse ; les changements plus larges nécessitent une passe complète de re-qualification.
-
Défendre l'outil dans les audits clients
Les assesseurs OEM et Tier-1 attendent des limites de cas d'usage documentées et un référent nommé pour les questions sur l'outil pendant l'assessment.
Effort réaliste : plusieurs personne-mois pour la qualification initiale, plus la maintenance courante pour chaque release — indépendamment de la rapidité avec laquelle les algorithmes eux-mêmes peuvent être écrits.
MCSA est qualifié
MCSA est disponible comme outil safety qualifié — le travail de qualification a été fait et est maintenu en exploitation.
Qualifié selon ISO 26262-8
MCSA v5.0.0 est qualifié selon ISO 26262-8 Clause 11. Le périmètre de qualification et les limites des cas d'usage sont documentés.
Preuves disponibles sur demande
Rapport de validation, documentation des cas d'usage et preuves de régression sont disponibles pour clients et assesseurs — sous NDA si nécessaire.
Re-qualifié à chaque release
Chaque release MCSA passe par la passe de re-qualification définie avant livraison. Les nouvelles versions arrivent chez les clients sans surcharge de qualification de leur côté.
Support outil pendant les audits
Nous participons aux conversations avec les assesseurs et fournissons des preuves sur les cas d'usage, les limites et les limitations connues — directement par le tool developer.
Ce que MCSA livre techniquement
Exprimé comme outcomes — pas comme catalogue d'algorithmes, mais comme ce sur quoi vous pouvez compter :
-
Entrée basée sur l'architecture
Description FtaDSL textuelle et versionnable avec fonctions, ports, interfaces (INT) et sémantique de propagation des défaillances (OIM, littéraux COND, taux ISF/SF/TF).
-
Génération automatique de l'arbre de défaillances
Généré depuis l'architecture — aucune maintenance manuelle de l'arbre, aucun coût de synchronisation entre architecture et FTA.
-
Minimal cut-sets jusqu'à l'ordre choisi
Avec métriques KPI (FCI, RRW, IMP, SEN, priorité), marqueurs SPOF et analyse common-cause pour les structures de transfert.
-
Validation et interprétation assistées par LLM
Vérification indépendante de la plausibilité de l'entrée et aide à l'interprétation des résultats. L'analyse elle-même reste déterministe et indépendante du LLM.
-
Reproductible et auditable
Même entrée, même sortie. Chaque calcul est traçable — un prérequis pour le safety case et l'audit.
Ce que vous obtenez en tant que client — au-delà de l'outil
-
Expertise ingénierie qualifiée
Le tool developer est un functional safety engineer, pas seulement un software engineer. Les réponses du support viennent de la perspective safety.
-
Aide à la modélisation
Aide à mettre en place la structure FtaDSL, les schémas OIM et à interpréter les premiers résultats de cut-sets — jusqu'à ce que le savoir-faire de modélisation soit en interne.
-
Intégration dans les processus safety existants
MCSA s'intègre avec la gestion des exigences, le tracing et le CI. Aucune île d'outil isolée.
-
Présence d'audit sur demande
Sur site lors des conversations avec les assesseurs si nécessaire — en tant que tool owner, pas en tant que voix marketing.
-
Options de déploiement
SaaS sur mcsa.appliedfusa.de ou installation on-premise pour environnements confidentiels (air-gapped possible).
Build vs. buy en un coup d'œil
Pas de caricature, pas d'histoire à sens unique — les lignes reflètent l'effort réel de projets safety. Développer en interne est une option légitime avec des coûts nommables.
| Aspect | Développer en interne | Utiliser MCSA |
|---|---|---|
| Implémentation algorithmique | Plusieurs personne-mois de travail C++ (MOCUS, BDD, minimisation). Les algorithmes sont publiés — aucun risque de recherche. | Fait, en usage live. |
| Qualification d'outil selon ISO 26262-8 | Qualification initiale typiquement 3–6 mois : plan de validation, test corpus, preuves, documentation. | Achevée pour v5.0.0 ; preuves disponibles sur demande. |
| Re-qualification par release | Responsabilité interne : delta-analyse plus tests de régression à chaque modification. | Inclus à chaque release. |
| Support audit | Géré en interne par l'équipe qui connaît l'outil — mobilisation supplémentaire de personnel pendant les audits. | Géré par le tool developer, sur site si nécessaire. |
| Expertise de modélisation (FtaDSL, OIM) | Doit être construite en parallèle de l'outil — ou achetée à l'extérieur. | Aide directe à la modélisation jusqu'à ce que le savoir-faire soit en interne. |
| Time-to-first-result | Plusieurs mois jusqu'au premier résultat de cut-set qualifié. | Quelques jours après la mise en place du modèle. |
| Maintenance courante | À budgéter en interne : bugs, upgrades de compilateur, mises à jour de toolchain. | Partie du service. |
Quand développer en interne reste le bon choix
Build vs. buy n'a pas de réponse universelle. Trois constellations dans lesquelles développer en interne est honnêtement la meilleure voie :
Une grande équipe safety interne avec une demande à long terme
Un investissement de qualification ponctuel s'amortit sur des dizaines de projets. Si vous avez déjà un groupe safety tools qui maintient d'autres outils, un moteur FTA en est une extension cohérente.
Une stratégie de tool-platform existante
Si votre organisation maintient une toolchain safety dans laquelle l'analyse FTA doit s'intégrer (modèle de données partagé, single sign-on, CI conjoint), un outil interne est le choix cohérent.
Contexte de recherche ou académique
Si vous prototypez des algorithmes, publiez des variantes ou enseignez aux étudiants, vous avez besoin du contrôle complet du stack — une boîte noire qualifiée est le mauvais instrument.
Si l'une de ces constellations vous correspond, une conversation reste utile — parfois un usage partiel (MCSA comme implémentation de référence pendant votre propre développement) est l'étape intermédiaire la plus économique.
Une conversation informelle ou une démo ?
En 30 minutes nous clarifierons si MCSA convient à votre projet — ou nous expliquerons pourquoi non. Sans pression commerciale.