Développement des 4 méthodes, études sur la sûreté et la sécurité des exploitations
4 4 Codes, qualification et incertitudes dans l analyse de sûreté 174 4.1 Les logiciels critiques, quels enjeux pour l évaluation? 177 4.2 Le vieillissement sous irradiation des cuves de réacteurs 184 nucléaires à eau sous pression 4.3 Expertise des méthodes d évaluation des incertitudes 195 du code CATHARE dans le programme international OCDE BEMUSE 4.4 Processus de qualification des formulaires de criticité 202 et exemple d'utilisation dans le domaine de l'expertise de criticité 4.5 Influence de la représentation mathématique 214 des connaissances imparfaites dans le traitement des incertitudes flashinfoflashinfoflashinfoflashinfoflashinfoflash 4.6 Vers une étude probabiliste de sûreté (EPS) de niveau 2 220 pour le palier 1 300 MWe 4.7 Réexamen des critères associés au combustible 220 4.8 En quelques dates / Soutenances de thèses et autres faits marquants 221 IRSN - Rapport scientifique et technique 2006
41 Codes, qualification et incertitudes dans l analyse de sûreté On fait appel à des études dites «de dimensionnement» dans la conception de tous les ouvrages industriels dont les réacteurs nucléaires et les installations du cycle font partie. Elles ont pour objectifs de déterminer, individuellement et dans leur ensemble, les performances en fonctionnement des systèmes qui les composent, leur robustesse dans les situations incidentelles et accidentelles et d en évaluer la fiabilité. Ces études sont effectuées à l aide d outils de calcul dont la représentativité vis-à-vis des phénomènes physiques modélisés et, en conséquence, la complexité n ont cessé de s accroître avec l affinement de la représentation géométrique, la sophistication des modèles mathématiques, la montée en puissance des capacités de calcul scientifique et la mise en œuvre du couplage entre codes. Les outils de calcul ne sont pas seulement un assemblage des codes, assortis de leurs logiciels d interface homme-machine et d exploitation, mais aussi et surtout ils enferment tout un patrimoine d expériences et de connaissances, consolidées dans ce que l on appelle de façon générique les méthodes ou schémas de calcul. Ces méthodes doivent obtenir une certification formelle de qualification avant toute utilisation pour les études de conception et/ou les vérifications de sûreté, à l issue d un cheminement complexe comportant en général deux étapes distinctes et complémentaires, qui peuvent s enchaîner ou s enchevêtrer tout au long d un processus laborieux : la validation par moyen de comparaison avec d autres schémas ayant des performances similaires, s ils existent. A minima, la validation des modèles mathématiques et de leur chaînage ; la qualification proprement dite, par comparaison des résultats du calcul avec un inventaire assez large et représentatif de données expérimentales, rendues disponibles par l expérimentation sur maquette ou par le retour d exploitation en fonctionnement normal ou en transitoire. 174 Développement des méthodes, études sur la sûreté et la sécurité des exploitations
4 Les modèles de calcul comportent toujours un niveau incompressible d incertitudes qui affecte les paramètres de conception en raison de : la faiblesse des modèles numériques, qui comportent toujours un certain nombre d hypothèses et d approximations ; le caractère nécessairement limité des échantillons de données expérimentales et de leur représentativité partielle par rapport aux conditions de conception ; la fiabilité des chaînes de mesure et le processus de reconstitution utilisé pour la génération des données expérimentales ; et l incertitude inhérente au processus de qualification. Pour pallier cet inconvénient, les concepteurs adoptent des démarches d étude qui consistent à pénaliser les conditions de calcul par l introduction de conservatismes plus ou moins poussés et plus ou moins maîtrisés selon l époque, le niveau de connaissance et le risque potentiel engendré par une défaillance éventuelle. L élément essentiel et déterminant de l analyse de sûreté est justement l appréciation critique de ces conservatismes, non seulement par rapport aux situations de fonctionnement normal, mais surtout par rapport aux accidents de dimensionnement et, depuis peu, hors dimensionnement. Tous les articles présentés dans cette section ont une relation plus ou moins directe et plus ou moins étroite avec les incertitudes, leur origine, leur propagation et leurs conséquences sur l analyse de sûreté. Soit parce qu ils se proposent de mettre en valeur la pertinence et la robustesse du processus de qualification d un schéma de calcul et de déterminer l incertitude engendrée par son utilisation, ce qui constitue une condition essentielle de son utilisation dans l expertise de sûreté : «Processus de qualification des formulaires de criticité et exemple d utilisation dans le domaine de l expertise de criticité», d Isabelle Duhamel, Éric Létang, Gilles Daumen, IRSN - Rapport scientifique et technique 2006 175
4 Igor Lebars, a comme objectif la prévention du risque de criticité dans les stockages et les transports de matières nucléaires (voir chapître 4.4) ; «Le vieillissement sous irradiation des cuves de réacteurs nucléaires à eau pressurisée»,de Bernard Monnot, conjugue l analyse du retour d expérience et le questionnement sur la modélisation et étudie, avec pertinence et justesse, le mécanisme de la fragilisation des aciers, notamment des cuves, dans la perspective de l allongement de la durée de vie des réacteurs REP (voir chapître 4.2) ; soit parce qu ils visent à évaluer les conséquences des incertitudes dues à la variabilité des données d entrée d un processus et aux imprécisions touchant les structures des modèles et les paramètres utilisés pour définir la relation entre les données d entrée et la réponse : «L'évaluation des méthodes d'incertitudes du code CATHARE dans le programme international OCDE BEMUSE», de Jérôme Joucla, répond à l objectif majeur pour l Institut de s approprier les méthodes statistiques pour l évaluation des incertitudes dans les études de sûreté (voir chapître 4.3) ; «Influence de la représentation mathématique des connaissances imparfaites dans le traitement des incertitudes», d Éric Chojnacki et Catherine Mercat-Rommens,met en relation l évaluation des incertitudes, la caractérisation d un résultat expérimental ou numérique et la prise de décision (voir chapître 4.5) ; l article de Jean Gassino et Pascal Régnier «Les logiciels critiques,quels enjeux pour l évaluation» mérite une mention à part.tout en démontrant la fiabilité et la robustesse de ces logiciels face aux défaillances matérielles, cet article ouvre un questionnement sur les conséquences non maîtrisées, en termes de fiabilité et de sûreté, des erreurs les affectant à la conception et de leur propagation (voir chapître 4.1) ; ces cinq articles,sans avoir la prétention à l exhaustivité, présentent un panorama à la fois large et varié des activités menées par l IRSN dans le domaine des études et recherches en support de l expertise face au problème des incertitudes, leur genèse,leur propagation,et, in fine,leur impact sur le comportement des systèmes et/ou les actions de l homme. Un domaine qui constitue un axe stratégique et privilégié de développement à moyen et long termes pour l Institut. Ils fournissent aussi une base solide de départ pour les réflexions à venir sur les systèmes évolutionnaires et/ou novateurs, notamment dans le cadre de GEN-IV et d ITER. Martial JOREL Direction de la sûreté des réacteurs 176 Développement des méthodes, études sur la sûreté et la sécurité des exploitations
4.1 Les logiciels critiques, quels enjeux pour l évaluation? Jean GASSINO, Pascal RÉGNIER Bureau d analyse des systèmes électriques et du contrôle-commande Le domaine des hautes technologies fait de plus en plus appel à des logiciels pour réaliser des fonctions de sûreté, et c est le cas en particulier de l industrie nucléaire. Ces logiciels sont dits «critiques» car leur éventuel mauvais fonctionnement peut avoir des conséquences catastrophiques, par exemple le dysfonctionnement des commandes de vol d un avion ou l absence d arrêt d urgence d un réacteur nucléaire dans une situation accidentelle. Leur complexité pose des problèmes de validation spécifiques, qui conduisent les évaluateurs à mener des actions d analyse et de R&D particulières. 4.1 Pour le nucléaire, il s agit de logiciels de contrôle-commande qui agissent en temps réel sur l installation pour la maintenir ou la ramener dans un état sûr. Ainsi, sur 24 des réacteurs de puissance d EDF, des logiciels sont chargés de déclencher l arrêt automatique dans la demi-seconde suivant la détection d un évènement anormal tel que l augmentation excessive du flux neutronique ou de la température du cœur. Ces mêmes logiciels sont conçus pour gérer automatiquement les 30 premières minutes d un incident ou d un accident afin d éviter aux opérateurs d avoir à prendre des décisions dans l urgence. Ces logiciels critiques sont un des moyens mis en œuvre au titre de la défense en profondeur pour assurer la sûreté d un réacteur. D une part celui-ci est conçu et exploité de façon à ne pas avoir, en principe, à solliciter l action d un logiciel critique.d autre part,d autres systèmes et dispositions d organisation palliatifs prennent le relais si une telle action s avère en définitive nécessaire mais ne s effectue pas comme prévu. Cependant les logiciels critiques appartiennent à la ligne de défense principale, et c est la base même de la démarche de sûreté que de réaliser chaque ligne de défense du mieux possible, comme si elle était indispensable. Par ailleurs, une fonction critique s exécute non pas sur un calculateur unique, mais sur un système composé de plusieurs calculateurs identiques redondants (en général quatre), incluant des dispositifs de surveillance du matériel par le logiciel et vice-versa. Ces dispositions permettent d assurer la réalisation de la fonction malgré une ou plusieurs pannes du matériel. Elles n ont cependant que peu d efficacité vis-à-vis des erreurs de conception des logiciels. Ainsi le bon fonctionnement des logiciels critiques constitue un point clé pour la sûreté nucléaire. Cet article présente le point de vue de l évaluateur sur les moyens permettant d obtenir et de démontrer un très haut niveau de confiance dans ces logiciels, alors que les logiciels grand public semblent voués à des dysfonctionnements chroniques et que les exemples de défaillances abondent dans cette industrie. IRSN - Rapport scientifique et technique 2006 177
4.1 Limites scientifiques et techniques Le logiciel d un automate de sûreté lit cycliquement des entrées représentant l état du processus physique, et calcule des sorties : commandes, ordres de protection, etc. Ce calcul présente deux caractéristiques : il est discontinu du fait de l utilisation d instructions conditionnelles du type «if (condition) then do A else do B». Ainsi, une infime variation des grandeurs d entrée peut faire basculer du traitement A vers le traitement B, qui peut être complètement différent ; il est complexe, car le nombre de discontinuités est souvent gigantesque. Un petit programme contenant 1 000 instructions «if» pourrait découper l espace des entrées en 2 1000 10 300 régions séparées par des discontinuités. De plus, ces instructions étant en général répétées itérativement dans des boucles, le nombre de cas potentiellement différents augmente exponentiellement avec le nombre de ces itérations. La vérification de tels programmes est donc un problème inaccessible à tout traitement systématique. En effet : la combinatoire des entrées (par exemple : 50 entrées codées sur 12 bits conduisent à 2 600 10 180 valeurs différentes) empêche définitivement la vérification «rouleau compresseur» par test exhaustif, même si l on disposait d un moyen permettant d effectuer des millions de tests par seconde, et surtout de décider pour chacun d eux si le résultat est correct ou non. Le test doit donc être pratiqué en liaison avec une analyse permettant de sélectionner les cas adéquats ; cette même combinatoire empêche le retour d expérience de jouer un rôle crédible : l observation pendant des millions d années du fonctionnement de millions d exemplaires d un logiciel ne couvrirait qu une infime partie de l espace d entrée. De plus, le fonctionnement discontinu évoqué ci-dessus fait que des conditions similaires du processus physique contrôlé peuvent en fait activer des traitements différents ; toutes les fonctions exécutées par un programme (calcul de la sortie 1, calcul de la sortie 2, etc.) partagent des ressources matérielles et logiques (mémoire, processeur, etc.), de sorte qu une erreur dans une fonction peut en faire défaillir une autre même si elles n ont apparemment aucun traitement ni aucune variable en commun. Les méthodes basées sur l étude de la propagation des défaillances au niveau fonctionnel sont donc non sûres en matière de logiciel, puisqu elles négligent des canaux essentiels de propagation qu il est par ailleurs en pratique impossible de modéliser ; enfin, il convient de noter pour ce qui concerne l utilisation éventuelle de méthodes statistiques que, bien que très complexe et discontinu, le calcul réalisé par un programme est parfaitement déterministe : si l on attribue la valeur d exactitude 1 à une exécution donnant le résultat correct et 0 dans le cas contraire, l exactitude d une exécution est déterminée avant qu elle ait lieu, par l état des entrées. Elle a par conséquent selon les cas une espérance mathématique égale soit à 0 soit à 1. Ce comportement est fort différent de celui par exemple du lancer d une pièce de monnaie auquel on attribue 0 pour pile et 1 pour face : la valeur d un lancer n est pas déterminée avant qu il ait lieu. Chaque lancer a une espérance mathématique égale, comprise entre 0 et 1 (0,5 si la pièce est équilibrée). Ainsi, les valeurs d exactitude des différentes exécutions d un programme n ont pas du tout la même distribution, au contraire des différents lancers d une pièce. Cela interdit d utiliser les théorèmes statistiques (limite centrée, lois des grands nombres, etc.) pour faire des études probabilistes les concernant. Une autre source de difficultés provient des écarts irréductibles introduits lors de la conception du logiciel entre l expression des besoins et le programme finalement réalisé. En effet, si l on considère par exemple la conception d un système de protection : 178 Développement des méthodes, études sur la sûreté et la sécurité des exploitations
le besoin initial résulte d études d accidents qui décrivent chacune des fonctions principales en quelques phrases, par exemple l arrêt du réacteur lorsque la marge à l ébullition est trop faible ; ce besoin est transmis aux équipes de contrôle-commande qui l interprètent fonctionnellement : le calcul de la marge à l ébullition en tous points du cœur nécessite de nombreux capteurs et un traitement complexe, ainsi que des recalages périodiques en fonction de l usure du combustible.ce recalage impose par exemple de prévoir des moyens d interaction entre le programme et les opérateurs. De quelques pages, la description passe à des dizaines ; pour faire face aux pannes matérielles, les concepteurs du système de protection introduisent des redondances,donc des échanges d informations entre voies redondantes et des votes. Cela nécessite des traitements supplémentaires dont certains sont «visibles», comme les votes,mais d autres sont «enfouis» :protocoles de gestion des réseaux de communication entre ces voies, pilotes des cartes de communication, prise en compte des cas d erreur, des asynchronismes, etc. La description de la conception atteint des milliers de pages. Ainsi l expression initiale du besoin ne décrit qu une infime partie des fonctions du programme final,les autres provenant des choix de conception successifs. Cela ajoute une difficulté majeure à la réalisation des tests : décider si le résultat d un test est correct ou non est une décision sujette à erreur, puisqu il n existe pas de spécification complète. L approche dite des «spécifications formelles» vise à réduire cette difficulté.elle consiste à décrire mathématiquement le besoin,de façon à pouvoir garantir que le programme final possède les propriétés requises par ces spécifications. Malheureusement, les formalismes utilisés sont peu compréhensibles par les automaticiens et informaticiens industriels, et ces spécifications sont souvent plus volumineuses que le programme final (ou alors elles ne décrivent pas des aspects importants comme les interactions avec le matériel ou les relations temporelles entre différents programmes). Le problème de leur exactitude par rapport au besoin réel reste donc entier. Évaluation technique indépendante Malgré ces limites scientifiques et techniques, développer un logiciel sûr est possible à condition de respecter rigoureusement les quatre conditions suivantes, qui rendent sa réalisation très différente de celle d un logiciel courant : faire simple, c est-à-dire limiter au strict nécessaire les fonctions confiées au logiciel et l organiser selon une structure simple, telle que la répétition infinie d une séquence «lecture des entrées -> traitement -> émission des sorties» plutôt que selon un ensemble de processus communicants ; organiser de manière rigoureuse un processus de développement découpé en phases conclues par des revues formelles, et faire intervenir des personnes différentes en développement et en vérification ; procéder à de multiples vérifications, notamment concevoir et réaliser des campagnes de tests pertinentes d abord sur chacun des modules du programme, puis sur des assemblages de modules, puis enfin sur le programme complet dans sa configuration définitive ; prévoir dès la conception des dispositions, telles que la programmation défensive (abordée plus loin), pour rendre le programme aussi tolérant que possible à d éventuels défauts qui subsisteraient malgré les dispositions d évitement et d élimination des erreurs décrites aux points précédents. L évaluation par l IRSN intervient en aval de la réalisation du programme et de la documentation correspondante par le concepteur. Cette évaluation n est pas une vérification ni une validation, car ces actions ont déjà été réalisées par l exploitant et sont de sa responsabilité.il ne s agit pas de certifier un programme mais d acquérir une confiance objectivement justifiée en la capacité du logiciel à satisfaire les besoins de sûreté explicites et implicites de la centrale au moyen d analyses techniques et d un dialogue avec le constructeur. L évaluation débute par l examen des procédures et des plans qualité. Ceux-ci doivent être conformes à l état de l art et aux exigences réglementaires pour définir un cadre de travail propice au développement d un produit correct. Ces exigences incluent des actions de vérification après chaque étape, et l indépendance des équipes de vérification par rapport à celles de conception. Cependant,comme on l a vu,la plus grande partie du logiciel ne résulte pas directement des exigences initiales, mais est ajoutée lors des étapes de conception pour satisfaire des besoins résultant de décisions prises aux étapes précédentes. Le programme final n est pas le résultat d un processus de fabrication déterministe, ces décisions humaines étant des choix parmi les possibilités imaginées par le concepteur, sujettes à erreurs et à omissions. L examen des procédures est donc nécessaire mais non suffisant. L évaluation technique doit également inclure l examen des documents de conception, puisqu ils ont pour objet de décrire et de justifier les choix faits à chaque étape. Mais ces documents n indiquent que les choix qui ont été jugés importants par leur auteur, car il est impossible en pratique de décrire chaque détail du programme. L évaluation doit par conséquent porter aussi sur le programme lui-même. Pour illustrer la complémentarité entre ces différents points de vue, supposons qu un programme contienne une instruction telle que le calcul du logarithme d une variable, provoquant une erreur d exécution si cette variable est négative ou nulle. Cette menace peut être écartée en prouvant que dans tous les cas la variable est strictement positive lorsque l instruction en question est exécutée. 4.1 IRSN - Rapport scientifique et technique 2006 179
4.1 Mais cette preuve peut être impossible à apporter pour des raisons de complexité et d indécidabilité (1). Dans un tel cas, le concepteur peut utiliser la «programmation défensive», c est-à-dire par exemple tester la variable juste avant le calcul du logarithme, et, si elle est négative ou nulle, placer la sortie dans une position prédéfinie dite «sûre» (par exemple déclencher l arrêt du réacteur). Selon le rôle de la sortie considérée (arrêt du réacteur, injection de sûreté, etc.), il peut exister ou non une position prédéfinie, sûre dans tous les états du réacteur. L évaluateur doit donc considérer de multiples aspects (programme, documents de conception, actions de vérification faites, processus nucléaire, etc.) pour élaborer son avis. L indépendance de l évaluateur est indispensable parce que le développement d un programme est une activité humaine sujette à erreur, parce que la vérification ne peut pas être automatique ni complète puisque le besoin initial exprimé est incomplet et informel. La nécessaire vérification déjà effectuée par le constructeur est donc orientée par son bagage technique et sa culture industrielle, tout comme la conception qu il a effectuée, ce qui rend indispensable une contreexpertise technique indépendante. Fait Échec du premier tir d'ariane 5, à cause d'une petite erreur du programme de la centrale inertielle. La perte totale de contrôle a obligé à détruire le lanceur en vol. Panne du système de réservation de la SNCF. Le programme en cause fonctionnait depuis 12 ans. Panne d'un réseau de téléphonie mobile, malgré l'utilisation d'équipements redondants à haute disponibilité. Plusieurs personnes tuées par des surdoses massives délivrées par l'accélérateur médical Thérac 25. Un «ver», sorte de virus informatique, met hors service pendant plusieurs heures le panneau d'affichage de sûreté de la centrale de Davis-Besse. Un constructeur rappelle 680 000 voitures à cause de problèmes dans le contrôle du freinage, et décide d'enlever 600 fonctions logicielles inutiles. Leçon tirée «Le diable est dans les détails». Des détails minuscules, invisibles aux niveaux spécification et conception générale, peuvent faire échouer le système complet. Le retour d'expérience ne valide pas un logiciel. La redondance du matériel ne protège pas contre les erreurs du logiciel. Même si un programme n'est faux que dans quelques rares cas, ceux-ci peuvent se produire. Utiliser des technologies grand public (PC, Windows, SQL, TCP-IP ) dans des systèmes de sûreté les expose à d'innombrables attaques, même quand ils sont réputés isolés d'internet. Ajouter des fonctions peu utiles compromet la sûreté du système, même si elles sont réputées sans rapport avec les fonctions de sûreté. Besoin de R&D Tableau 1: Exemples d erreurs et leur interprétation. Les problèmes de complexité, de non-continuité, d indécidabilité et d absence de spécification complète se traduisent par des erreurs dont quelques exemples sont présentés en tableau 1. La colonne de droite rappelle des évidences qui sont malheureusement souvent oubliées. Tous ces cas concernent des systèmes développés au minimum sous assurance qualité, et souvent avec de fortes exigences de sûreté, ce qui montre encore une fois que le respect des procédures ne garantit pas l exactitude du programme final. L évaluation technique de ce dernier est indispensable, mais ne peut guère être efficace en l absence d outils : il serait très présomptueux de vouloir repérer et comprendre les innombrables cas d exécution d un programme réaliste sans aide. De plus, la difficulté du problème s accroît sans cesse car la taille des logiciels des systèmes de protection augmente d un facteur 10 à chaque génération, et des technologies de plus en plus complexes comme le multitâche (2) sont introduites. Un effort de R&D soutenu est donc essentiel pour bénéficier des meilleures solutions pratiques issues des avancées de la recherche scientifique. Travaux de R&D Les travaux de recherche et développement en informatique sont légion, mais ils sont consacrés dans la plupart des cas à des aspects méthodologiques assez superficiels visant à améliorer la productivité des équipes de programmeurs sans s attaquer au problème de la vérification, dont les difficultés scientifiques et techniques font que le moindre progrès nécessite des travaux longs et difficiles. Deux pistes se distinguent toutefois tant par leurs objectifs que par les résultats récemment obtenus et les perspectives ainsi ouvertes :il s agit de l analyse statique et de l évaluation de la couverture des tests. L analyse statique consiste à examiner les instructions du programme sans l exécuter, soit manuellement soit à l aide d un analyseur comme un outil logiciel, pour en extraire des informations valides dans un grand nombre de cas d exécution, idéalement dans tous les cas possibles. Cette approche vise à être plus générale que celle qui consiste à réaliser des tests, qui ne fournissent d information que pour les seules exécutions effectivement réalisées. Ces outils ont longtemps été limités à des analyses rudimentaires telles que le comptage de lignes, le calcul du taux de commentaires ou encore la vérification de règles de programmation élémentaires comme l utilisation systématique des parenthèses dans les formules arithmétiques, l organisation des constructions «if then else» imbriquées, le nommage des variables, etc. Ces renseignements témoignent d un certain niveau de qualité, mais ne sont pas directement corrélés à la présence d erreurs dans le logiciel, car ils se limitent à la forme du programme sans analyser sa fonctionnalité, ou «sémantique». 180 Développement des méthodes, études sur la sûreté et la sécurité des exploitations
Étape 1 Identification des menaces... if (x<10) y = x+5 else y = 10 endif... z= 1/(y-16) Étape 2 Résolution par propagation d'intervalle x [0..32 000] if x<10 x [0..9] Vrai Faux x [10..32 000] y = x+5 y = 10 y [5..14] y [10..10] Risque : division par zéro si y {16} Conclusion: {16} z = 1/(y-16) y [5..14] [5..14] = Ø => Pas d'erreur 4.1 Figure 1 : Illustration de l interprétation abstraite. Des principes d analyse sémantique, à très fort contenu mathématique, ont été élaborés depuis une trentaine d années, par exemple la logique de Hoare [1] ou l interprétation abstraite [2].Au-delà des exemples académiques, leur application à de véritables programmes demande d innombrables raffinements mathématiques, eux-mêmes très difficiles à programmer dans les outils d analyse. C est donc seulement depuis une dizaine d années que l analyse statique «sémantique» permet progressivement de traiter des programmes réels. Supposons que l on veuille vérifier que les opérations de division présentes dans un programme ne provoqueront jamais de défaillance à l exécution pour cause de diviseur nul. L interprétation abstraite, grossièrement illustrée par la figure 1, consiste à représenter la totalité des cas en ne manipulant que quelques informations, qui les enveloppent au sens de l abstraction choisie. Dans cet exemple, l abstraction consiste à représenter chaque variable par un intervalle contenant toutes les valeurs possibles. Au début du programme, l intervalle est défini par les plages de variation des entrées (0 à 32 000 dans cet exemple), puis il est propagé en tenant compte de l action de chaque instruction. Arrivé au dénominateur d une opération de division, il suffit alors de vérifier si l intervalle propagé contient ou non la valeur 0. Toutefois, l analyse ne peut en général pas conclure aussi aisément, notamment parce que les boucles posent des problèmes de complexité et de décidabilité redoutables (3). De façon plus pratique, l abstraction par intervalles montrée ici n est pas très performante : soit une variable A dans l intervalle [-5..5] et B = 1 - A, alors B est dans [-4..6]. Si plus loin une division par A + B est effectuée, l analyseur calculera l intervalle de A + B, soit [-9..11] et ne pourra exclure la possibilité d une division par zéro. Or, A + B est toujours égal à 1 d après la définition de B, et dans ce cas l analyseur a donc émis une fausse alarme (4). Des analyses plus sophistiquées, tenant compte par exemple des relations linéaires entre variables, sont nécessaires pour affiner les diagnostics dans de tels cas [3], toute la difficulté étant de trouver un compromis entre la précision de l abstraction (enveloppe aussi proche que possible des valeurs réelles) et la complexité de son calcul (en temps et en mémoire nécessaires). (1) Un problème est décidable au sens de la calculabilité s il existe une suite fixée d opérations mécaniques qui, dans tous les cas, donne le résultat en un nombre fini d étapes. Ainsi le problème de l existence de solutions réelles aux équations du second degré à une inconnue à coefficients réels est décidable : quels que soient les coefficients, le calcul du discriminant permet de répondre. Par contre l existence de solutions entières aux équations polynomiales quelconques à coefficients entiers est indécidable de ce point de vue. (2) Il s agit d exécuter plusieurs programmes en même temps sur le même calculateur, ce qui pose de difficiles problèmes de synchronisation. (3) Soit par exemple un petit programme (correspondant au problème dit «Conjecture de Syracuse») qui reçoit un entier positif X, et boucle sur l instruction suivante : «si X est impair, remplacer X par 3 X+1, sinon remplacer X par X/2». La boucle se termine quand X atteint la valeur 1, si cela se produit. Une valeur initiale égale à 3 conduit ainsi à la séquence 3, 10, 5, 16, 8, 4, 2, 1. Ce programme atteint-t-il 1 pour toute valeur initiale de X? (4) Cela ne pose pas de problème de sûreté, car l imprécision va toujours dans le sens de la fausse alarme. Toutefois, ces situations d incertitude doivent être revues manuellement une à une pour conclure, ce qui peut enlever tout intérêt à l outil si elles sont trop nombreuses. IRSN - Rapport scientifique et technique 2006 181