- Ce sujet contient 13 réponses, 4 participants et a été mis à jour pour la dernière fois par
, le il y a 5 années et 7 mois.
-
Messages
-
Bonjour. Quelqu’un peut-il avoir l’amabilité de m’indiquer pourquoi il n’existe pas de non-conformités liées à l’informatique en entreprise ?
Merci !
Hello !
Morteen, je ne comprends pas ta question. Peux-tu déjà définir son cadre de référence ? Peux-tu dire d’où tu tires « qu’il n’existe pas de non-conformités liées à l’informatique en entreprise » ? Peux-tu illustrer quel genre de NC tu envisages ?
Personnellement il me vient un exemple de « non conformité informatique » tout à fait d’actualité ces derniers temps, qui a été lourde de conséquences et a induit l’interdiction de vol des avions Boing 737 MAX : « Boeing reconnaît avoir été forcé de corriger un défaut dans le logiciel des simulateurs destinés à reproduire les conditions de vol et avec lesquels sont formés les pilotes du 737 MAX, avion impliqué dans deux catastrophes aériennes ayant fait 346 morts)« .
A+
Bonjour,
Pourriez-vous nous en dire plus sur le contexte de de votre question ? D’où tenez vous cette réflexion ou cette information ?
Parce que, dans mon expérience : il en existe et il s’en identifie et s’en enregistre régulièrement…
Bonjour et merci de vous préoccuper de cette question.
Je veux dire pas de non conformité selon l’ISO pour un développement informatique et donc pas de possibilité d’établir une « fiche de NC » concernant l’informatique, sauf si cette dernière concerne une procédure fonctionnelle. C’est ce que m’ont toujours expliqué les différents RAQ que j’ai côtoyé, et cela tiendrait au fait que personne ne peut s’assurer – du fait de la complexité de la chose – qu’un développement informatique correspond strictement et sans « bug » possible à la demande pour laquelle il a été réalisé.
Concernant l’exemple du logiciel de Boeing, je comprends bien qu’il s’agit d’une erreur de conception, mais je pense qu’il ne faut pas confondre « erreur » et « non-conformité », une non-conformité n’existant que relativement à une procédure, et non à un cahier des charges. Je me trompe ?
Hé bien, les différents RAQ que vous avez côtoyés participent chacun.e allègrement à faire en sorte de ne pas contribuer à améliorer ce qui peut l’être là ou cela peut être fait…
Pour ma part : il m’arrive régulièrement d’établir des constats (lors d’audits) ou des non-conformités (lors d’accompagnement ou de pilotage de systèmes de management) sur des aspects de développement informatiques au même titre que sur d’autres thématiques.
Maintenant, petit « décorticage » :
[1] … personne ne peut s’assurer – du fait de la complexité de la chose – qu’un développement informatique correspond strictement et sans « bug » possible à la demande pour laquelle il a été réalisé… : cela, c’est une légende urbaine pour les informaticiens qui veulent croire qu’il est normal de livrer un produit non-conforme. Il existe suffisamment de méthodes et d’outils (cycle en V, étapes de recettes, phasages, spécifications de besoins, fonctionnelles, techniques…) qui ont prouvé leur efficacité et de sociétés dont vous n’entendez pas parler parce qu’il n’y a pas lieu qu’elles fassent parler d’elles en faisant tomber des avions. Certes, toutes ces méthodes reposant sur des principes sains, peuvent voir leurs limites rapidement atteintes lorsqu’il est question d’économie, de coût, de limite de compétence, de vente de développements irréalistes ou irréalisables dans les délais etc… Le récent cycle « agile » vient complexifier cette perception parce que, bien déployé il apporte effectivement des résultats très intéressant, mal utilisé, il fait croire que l’erreur est normale.
[2] … Concernant l’exemple du logiciel de Boeing, je comprends bien qu’il s’agit d’une erreur de conception… : pour ma part, je n’en serais pas si sur. Si trouver « une faute » permettait de ne plus la reproduire, nous vivrions aujourd’hui dans un monde fort idéal. En effet, que des développements informatiques puissent engendrer des bugs, des incidents, des performances non atteintes, des failles est normal au nombre d’informations agrégées. Mais tout process, du plus simple au plus complexe, nécessite des process de validation, de vérification (tests, intégration, non régression… pour l’informatique) destinés à identifier ces non-conformités. Aussi, l’erreur est rarement « de conception » mais très souvent « d’incapacité à détecter les erreurs ou non-conformités par rapport aux attendus (spécifications, cahier des charges, simulations…) ». Tant que des personnes se focaliseront sur « l’erreur » et non le process permettant de réduire les erreurs et de les identifier aux étapes clefs : les erreurs continueront à faire tomber ces avions. Le génie, en revanche, est de faire croire (mais c’est si simple, si humain) au plus grand nombre qu’on a trouvé l’erreur, le fautif, et que tout va bien, et que cela ne se reproduira plus. De masquer les causes parce qu’il est économiquement plus efficace de gérer la crise que de la gérer ET revoir le fonctionnement (et là, votre quotidien fourmille d’exemples plus tous croustillants les uns que les autres : les failles de sécurité et les mots de passe qui continuent de s’évaporer, les crises économiques qui s’enchaînent pour les mêmes causes…).
[3] … il ne faut pas confondre « erreur » et « non-conformité »… : vous avez raison. Simplement, c’est une non-conformité que de ne pas détecter les erreurs.
[4] … une non-conformité n’existant que relativement à une procédure, et non à un cahier des charges. Je me trompe ?… : je pencherais plutôt pour un « oui » (vous vous trompez). Une non-conformité est effectivement par rapport à un référentiel : une procédure, une spécification, un cahier des charge, une attente même informelle d’un client ou bénéficiaire. Par exemple : si j’étais passager d’un avion n’ayant plus aucun contrôle et ne m’offrant plus que quelques minutes d’existence, je pense que je considérerais cela comme une non-conformité, même si les conditions générales de ventes de mon billet n’indiquaient pas en toutes lettres que mon transport à pour objectif de me garder en vie au moins jusqu’à l’arrivée à la récupération des bagages…
Hello
Morteen, ton passage « pas de conformité selon l’ISO pour un développement informatique et donc pas de possibilité d’établir une « fiche de NC » concernant l’informatique, sauf si cette dernière concerne une procédure fonctionnelle » n’est pas très clair (de quoi parles-tu vraiment et en regard de quelle exigence normative ?). Pourrais-tu illustrer un minimum ces deux cas avec des exemples d’école concrets liés à des exigences ISO 9001 identifiées ? Si tu veux discuter de NC, il faut dire de NC de quoi à quoi dans un référentiel. Accessoirement je crois deviner qu’un « développement informatique » c’est tout simplement un logiciel.
En attendant je fais l’hypothèse que ce « développement informatique » (?) peut être (ex perso supposés coller à ton propos) :
– Le développement d’un logiciel pour un client dans un agence WEB. Si le logiciel ne satisfait pas telle exigence du CdC client comme l’attend l’ISO 9001, c’est bien une NC de ce produit informatique ! Une « NC informatique » ? Une NC du SMQ (cf 8.2.3) ?
– Le développement d’un logiciel maison pour gérer et surtout mettre à dispo la documentation du SMQ. Si ce logiciel permet de consulter aléatoirement l’une ou l’autre des dernières versions de certains documents en laissant croire à chaque fois que c’est précisément la version en cours contrairement aux attentes ISO 9001, c’est bien une NC de cet outil informatique ! Une « NC informatique » ? Une NC du SMQ (cf 7.5.3) ?
Autres rebonds :
– Il n’est peut-être pas toujours facile ou voulu de « s’assurer – du fait de la complexité de la chose – qu’un développement informatique correspond strictement et sans « bug » possible à la demande » mais en tout cas si un bug est identifié à l’usage il y a bien NC à qqchose !
– En tout cas si une erreur de conception se manifeste par un bug informatique faussant le résultat attendu par le CdC il y a bien une NC quelque part… Pourquoi considères-tu qu’on ne doit pas parler de NC quand un produit est Non Conforme son cahier des charges ?
A+
PS : pourquoi transformer la notion « d’erreur » en « faute » ?
Merci.
Je prends note. Cela fait 20 ans que j’entends dire qu’il n’y a pas de NC en informatique, sauf concernant d’éventuelles procédures fonctionnelles. Vous me dites le contraire. Je vous remercie pour vos réponse détaillées et pour le temps que vous avez bien voulu consacrer à les rédiger. Vous me dites qu’il s’agit d’une « légende urbaine ». Soit. Pour répondre à Henri, nous parlons ici d’un développement maison dans un cadre quelconque qui donne un résultat. Ce résultat s’avère erroné. Prenons un exemple trivial: le résultat est un chiffre d’affaire selon certains critères (période, type de ventes, localisation des clients), le développeur n’ayant pas programmé correctement, le résultat est faux. Peut-on établir une fiche de NC dans ce cas ? Sur quelle base ? Prenons un exemple moins trivial: vous connaissez certainement l’histoire de ce que l’on appelle l’effet papillon. Selon que vous calculez avec 3 ou 4 décimales dans le même programme, vous obtenez des prévisions (ici, concernant des données climatiques) très différentes. Or, entre 3 et 4 décimales, la différence (de vitesse du vent) est ridiculement petite, de l’ordre de ce que génère le battement d’une aile de papillon. Cela remet en cause la pertinence du travail. C’est une non conformité ?
Je ne sais pas si je m’exprime bien, je ne suis pas qualiticien.
Hello,
Pour répondre à ta première question je dirais que oui c’est une NC car j’imagine sans peine que le cahier des charges précise d’avoir une résultat juste
Par ailleurs la solution est sensée être analysée et validée et la conception doit ensuite être testée et validé avant d’être mise en production/utilisée.
Après quelle que soit la solution conçue, dans tous les cas il convient de préciser le cahier des charges de plus en plus au fur et à mesure de l’avancée du processus de conception, jusqu’à avoir des spécifications techniques détaillées.
Or la précision des données d’entrée, à la décimale près est une des spécifications techniques qu’on peut être amené à prendre en compte. Donc oui, ça peut être vu comme une non-conformité de conception&développement si ça nuit à l’atteinte du résultat attendu par le client (et les spécs pas claires ou manquantes… c’est super fréquent!!).
Tout dépend du rôle du développeur là-dedans, s’il n’intervient que pour coder la solution qu’on lui a donné en sortie de conception ou s’il contribue à la conception de la solution à développer.
(suite)
Morteen…
– « Cela fait 20 ans que tu entends dire qu’il n’y a pas de NC en informatique, sauf concernant d’éventuelles procédures fonctionnelles« .
>> Demande à ceux qui te disent cela d’expliquer et justifier leur position avec un référentiel identifié.
– « Ton exemple trivial d’un
développementlogiciel maison : le résultat est un chiffre d’affaire selon certains critères (période, type de ventes, localisation des clients), le développeur n’ayant pas programmé correctement, le résultat est faux. Peut-on établir une fiche de NC dans ce cas ? Sur quelle base ?«>> Je répète d’une autre manière que tant que tu n’identifies pas un référentiel tu ne peux identifier aucune NC. Dans cet exemple c’est au moins le CdC reçu donné à l’informaticien pour concevoir ce logiciel… Si le résultat est faux c’est qu’il n’a pas combiné tous les critères d’entrée attendus ou pas de la manière attendue par le CdC. C’est donc bien une NC par rapport au CdC ! (j’écarte l’hypothèse que le processeur de l’ordinateur produise des erreurs de calculs avec de bonnes données…)
– « Calcul avec 3 ou 4 décimales… entre 3 et 4 décimales, la différence (de vitesse du vent) est ridiculement petite, de l’ordre de ce que génère le battement d’une aile de papillon. Cela remet en cause la pertinence du travail. C’est une non conformité ?«
>> La « pertinence du travail » (selon le nombre de décimales des calculs) se trouvent dans le CdC et non dans sa déclinaison lors du développement informatique (si celui-ci respecte ce CdC en ce qui concerne les décimales des calculs bien sûr). Ce n’est du ressort de l’informaticien de déterminer comment modéliser et calculer la vitesse du vent et s’il faut le faire à 3 ou 4 décimales, c’est au météorologiste qui demande le logiciel !
A suivre…
« Pour répondre à ta première question je dirais que oui c’est une NC car j’imagine sans peine que le cahier des charges précise d’avoir une résultat juste ».
Bonjour.
Cependant, un « résultat juste », en informatique, cela n’existe pas. Un programme informatique donne des résultats. On ne les qualifie jamais de « justes », tout au plus peut-on leur affecter un coefficient de fiabilité ou un niveau de précision. D’autre part, la vérification d’un programme informatique peut-être plus ou moins poussée mais ne peut être absolue, cela n’existe pas. Quels que soient les moyens (de vérification) mis en oeuvre, il est impossible d’affirmer que le programme ne contient aucune erreur, cela tient au fonctionnement même de l’outil informatique (on a vu par le passé une simple division donner un résultat faux et cela à cause d’une erreur de codage dans le processeur (Intel Pentium) lui-même). On peut affirmer qu’il n’y a pas d’erreur dans un programme comme X=Y/Rac(2121), sauf que si le processeur ne sait pas faire le calcul, le résultat est faux (bien que le programme soit sans erreur).
La possibilité d’erreur « cachée » est inhérente au fonctionnement même de l’outils informatique. C’était à mon avis la raison pour laquelle il ne peut y avoir de NC en informatique (je le croyais en tout cas) et je cherchais confirmation auprès de vous. Mais visiblement, vous ne confirmez pas.
Merci beaucoup.
Le CA calculé est juste ou pas, bilan comptable à l’appui.
Je ne parle pas dans l’absolu. Les fonctionnalités définies comme critiques doivent être identifiées, décrites précisément et une AMDEC doit-être menée. Des actions doivent être mises en place pour se prémunir des risques les plus importants ou au moins les plus probables.
Pour être exigeant, chaque paramètre défini et associé directement ou indirectement à une des fonctions critiques doit être testé et vérifié dans toutes les valeurs qu’il peut prendre. Il convient également de créer les environnements de développement et les environnements de tests adéquats et de faire des stress-tests plutôt poussés si l’enjeu est important sur les fonctionnalités essentielles comme sur leurs dépendances. C’est un peu en gros la démarche qu’on a dans le spatial, c’est pas parfait mais ça a tendance à fonctionner si on est scrupuleux.
Le système parfait n’existe pas mais avoir l’assurance que les fonctionnalités requises fonctionnent à 99.99% des cas de figures envisageables est possible. Après il faut s’en donner les moyens et surtout ne pas se contenter du CIBCC « classique »
Pour les autres cas il vaut mieux s’assurer d’avoir un code versionné, commenté et « débogable » facilement. Ca c’est une autre paire de manche
» La « pertinence du travail » (selon le nombre de décimales des calculs) se trouvent dans le CdC et non dans sa déclinaison lors du développement informatique (si celui-ci respecte ce CdC en ce qui concerne les décimales des calculs bien sûr). Ce n’est du ressort de l’informaticien de déterminer comment modéliser et calculer la vitesse du vent et s’il faut le faire à 3 ou 4 décimales, c’est au météorologiste qui demande le logiciel ! «
Non, là vous décrivez le process du point de vue d’un qualiticien ?
En fait, le nombre de décimales utilisé initialement est celui de l’instrument de mesure de la vitesse du vent.
L’instrument en aurait donné 10, le programme en aurait utilisé 10. Et le résultat aurait sans doute été tout autre.
Où l’on voit bien que l’informatique ne peut donner de résultat incontestable.
Le principe de la conception dont je parle est justement qu’il faut concevoir la solution, que le client n’a pas, par définition. Si on se contente de produire exactement, à la virgule près, ce qu’on nous a commandé, on appelle ça de la production
C’est bien pour ça que je parle de « processus de Conception ET de développement » (enfin « moi », façon de parler, c’est surtout l’ISO 9001 qui en parle).De façon plus générale, si je peux me permettre j’ai du mal à saisir ta démarche…
Tu poses une question tout en étant sûr et certain de la réponse, inventes un exemple qui évolue au fur et à mesure des échanges/réponses et pour te donner raison…
De façon plus vaste je te conseillerais de lire le chapitre 8.3 de l’ISO 9001:2015 (et le comparer au 8.5), tu devrais trouver réponse à tes questions
Bonne journée,
@+
- Vous devez être connecté pour répondre à ce sujet.