Innovation avec les systèmes vitaux

Chaque entreprise possède une infrastructure « critique ». En règle générale, cela signifie que si le système se déconnecte, certaines parties (ou la totalité) de l'entreprise s'arrêteront brutalement jusqu'à ce que les techniciens puissent le faire fonctionner à nouveau. Cela se produit souvent lorsque des mises à niveau logicielles, matérielles ou réseau importantes sont nécessaires : les systèmes nouvellement déployés contiennent des bogues inattendus qui provoquent une défaillance du système, ou les utilisateurs font des erreurs avec le nouveau système parce qu'ils ne le connaissent pas, et la productivité s'arrête jusqu'à ce que les techniciens puissent résoudre les bugs de déploiement ou former les utilisateurs. Dans la plupart des cas, une période d'indisponibilité ou de productivité réduite est un risque acceptable en échange de la promesse d'amélioration des performances et de l'efficacité des nouvelles technologies, mais ce n'est pas universel. La plupart des entreprises peuvent se permettre un certain temps d'arrêt sans risquer beaucoup de revenus ni contrarier leurs clients.

Mais que se passe-t-il lorsque les systèmes que vous devez modifier sont des systèmes vitaux , où la sécurité des personnes dépend de la capacité à utiliser le système de manière fiable ?

Cet article s'éloigne du développement logiciel plus traditionnel sur lequel nous passons la plupart de notre temps et, à la place, se penche sur l'élément humain dans les systèmes vitaux. Mes réflexions sur ce sujet découlent de mon expérience en tant que directeur des technologies de l'information pour un service d'ambulance 911, en tant que spécialiste de la technologie pour une organisation internationale d'intervention en cas de catastrophe humanitaire et avec mon doctorat. en intégration des systèmes humains complétée au Massachusetts Institute of Technology.

Avant de commencer, j'aimerais expliquer pourquoi cela peut être pertinent pour vous. Bien qu'il ne soit pas évident que votre projet implique réellement un système vital, il est beaucoup plus probable que vous ne le pensez. Tous les sujets suivants sont éligibles, ainsi que d'innombrables autres sujets :

• Automobile. Vous travaillez sur un projet avec un constructeur automobile ou l'un de ses fournisseurs ? Recruté à la sortie de l'université par une start-up de voitures autonomes ? Freinage automatique, régulateur de vitesse, contrôle de voie, vision par ordinateur, reconnaissance d'obstacles, modules de contrôle électronique du moteur, etc. Chacun de ces éléments est un système vital, où une panne peut être fatale.
• Aviation. Lorsque vous êtes à 30 000 pieds dans les airs, presque toutes les pannes du système peuvent être vitales. Compte tenu des événements récents avec le Boeing 737 MAX, il existe des systèmes vitaux évidents de pilote automatique et de contrôle de vol informatisé, mais il y a aussi beaucoup de choses auxquelles vous ne pensez peut-être pas. À la maison, si le ventilateur de votre système CVC tombe en panne et produit un peu de fumée, vous ouvrez la fenêtre ou vous sortez pour respirer de l'air frais. Avez-vous déjà essayé d'ouvrir la fenêtre et de sortir pendant un vol transatlantique ? Même les systèmes les plus élémentaires, des prises de courant dans la cuisine aux freins sur les roues du chariot à boissons, peuvent être vitaux à bord des avions.
• Communications. La plupart des développeurs ou des ingénieurs travailleront, à un moment donné de leur carrière, sur un projet de système de communication à un titre ou à un autre. Pour beaucoup de gens, les télécommunications ne semblent pas vitales au départ ; après tout, la civilisation se portait très bien avant les téléphones et Internet. En tant que personne qui a été déployée dans des zones sinistrées où l'infrastructure des télécommunications a été détruite, permettez-moi de vous dire ce qui se passe réellement : les gens tombent gravement malades ou se blessent et ne peuvent pas appeler le 911 ; les résidents âgés ne peuvent pas appeler leurs enfants pour leur demander d'aller chercher leurs ordonnances à la pharmacie; les intervenants d'urgence ne peuvent pas communiquer avec leurs répartiteurs ou entre eux ; et les personnes qui ne peuvent pas contacter les membres de leur famille s'inquiètent et se mettent dans des situations extrêmement dangereuses pour essayer de les retrouver. Les systèmes de communication sont absolument vitaux.

Dans le monde d'aujourd'hui, fortement dépendant de la technologie, des projets que vous n'avez jamais considérés comme semi-importants pourraient finir par devenir un élément vital d'un système vital.

Mais si ce n'est pas cassé, ne le répare pas

Avez-vous déjà entendu ou utilisé le mot « patrimoine » en relation avec un système technologique ? C'est un mot fort, évoquant des pensées de traditions, de lignées et de temps difficiles de longue date. Dans le monde de l'ingénierie, il est utilisé pour désigner des conceptions qui existent depuis longtemps et dont il a été prouvé qu'elles fonctionnent de manière fiable et sont souvent considérées comme un trait souhaitable pour réduire les risques. En réalité, c'est un euphémisme pour une technologie archaïque qui n'a jamais été mise à jour en raison de l'aversion au risque, et elle est omniprésente dans les industries où les défaillances du système peuvent entraîner des conséquences désastreuses.

Il y a une bonne raison derrière cette affinité envers les logiciels et le matériel patrimoniaux. Il est connu pour fonctionner, il est peu probable que des bogues inconnus surviennent et ses coûts sont stables et prévisibles. Un excellent exemple est l'industrie du vol spatial : le vaisseau spatial russe Soyouz a lancé des astronautes dans l'espace pendant plus de 50 ans avec seulement des révisions mineures pendant cette période, et il continue d'être utilisé car il est fiable et sûr. Malheureusement, cela signifie qu'il est également extrêmement inefficace par rapport aux conceptions modernes : alors que le Soyouz coûte à la NASA 81 millions de dollars par siège pour transporter des astronautes vers la station spatiale en utilisant son matériel patrimonial, SpaceX et Boeing devraient proposer des sièges pour 58 millions de dollars chacun. en utilisant leurs conceptions de fusées modernes.

Il est compréhensible que peu de personnes souhaitent mettre à niveau d'anciens systèmes qui fonctionnent encore ; les cadres ne veulent pas prendre de risque, les techniciens ne veulent pas s'occuper du mystérieux serveur dans le placard avec une disponibilité de 12 ans, et les clients ne veulent pas avoir à apprendre de nouvelles conceptions. Malheureusement, il existe un point de bascule entre la minimisation des risques et les économies de coûts : les conceptions patrimoniales devront éventuellement être mises à niveau, même dans les environnements à haut risque .

Le reste de cet article couvre certaines des étapes les plus importantes du processus lorsque vos systèmes sont vitaux, tels que ceux utilisés par les premiers intervenants, les unités militaires ou les avions.

Convaincre les cuivres

D'après mon expérience, l'étape la plus difficile du processus est peut-être de convaincre les décideurs et les parties prenantes que des mises à niveau sont nécessaires. Les systèmes qui fonctionnent dans des environnements vitaux sont souvent régis par une réglementation juridique et une politique d'organisation étendues, ce qui signifie que vous devez les convaincre qu'ils ne doivent pas seulement prendre le risque et dépenser de l'argent, mais qu'ils doivent également s'engager dans ce qui pourrait facilement être plusieurs années de coupures de ruban bureaucratiques. L'opposition la plus forte à laquelle vous serez confronté viendra probablement de l'équipe juridique, qui exposera dans les moindres détails la responsabilité potentielle à laquelle vous ouvrirez l'organisation en introduisant une nouvelle technologie. Ils ont raison : la responsabilité est un problème majeur , et si quelque chose se casse et que quelqu'un se blesse ou meurt, cela pourrait représenter un énorme fardeau éthique, réputationnel et financier.

Que vous travailliez avec une société Fortune 500 ou avec votre service d'incendie volontaire local, cela revient toujours à la même chose : l'argent. Les entreprises ne veulent pas le perdre, et les organismes à but non lucratif n'ont pas grand-chose avec quoi travailler en premier lieu. Le seul moyen fiable que j'ai trouvé pour convaincre les dirigeants d'une organisation de prendre le risque de changer un système vital est de démontrer que, de manière probabiliste, ils sont soit plus susceptibles de gagner/économiser de l'argent que d'en perdre, soit qu'ils peuvent réduire leur responsabilité en modernisant leur technologie et en améliorant la sécurité.

Cela signifie que vous devez faire le calcul. Quelle est la probabilité qu'il y ait des temps d'arrêt prolongés ou des pannes futures dues à des bogues (sur la base de déploiements précédents dans votre organisation ou de données d'autres organisations) ? Quel est l'impact attendu en cas d'échec, et combien cela coûterait-il ? A l'inverse, quels sont les gains de performance ou de fiabilité attendus, et que vaudraient-ils ? Si vous pouvez montrer qu'il y a une forte probabilité que vous soyez gagnant, il y a de fortes chances que vous obteniez le feu vert.

Il ne s'agit pas de vous

Vous connaissez peut-être l'expression « par des ingénieurs, pour des ingénieurs », un idiome suggérant que les ingénieurs ont construit quelque chose pour être utilisé par des personnes ayant des qualifications similaires aux leurs. C'est un phénomène extrêmement courant et a été l'un des principaux facteurs déclenchants de l'essor des études sur l'utilisabilité des ordinateurs au début des années 1990. En tant qu'ingénieurs, nous avons souvent des modèles mentaux du fonctionnement des systèmes technologiques différents de ceux de l'utilisateur final moyen, ce qui conduit à une tendance à concevoir des systèmes en supposant que l'utilisateur final sait déjà comment cela fonctionne. Dans les systèmes conventionnels, cela conduit à des erreurs et à des clients mécontents ; dans les systèmes vitaux, cela peut entraîner la mort.

Prenons le cas du vol 447 d'Air France. Le 1er juin 2009, l'Airbus A330 survolait l'océan Atlantique en route de Rio de Janeiro à Paris. Des cristaux de glace ont obstrué les tubes de Pitot, provoquant des incohérences dans les mesures de la vitesse de l'air. L'ordinateur de vol a désengagé le pilote automatique, reconnaissant qu'il ne pouvait pas piloter l'avion lui-même de manière fiable avec des données de vitesse incorrectes. Il s'est ensuite placé dans un mode "enveloppe de vol étendue" , ce qui a permis aux pilotes d'effectuer des manœuvres que l'ordinateur ne permettrait normalement pas. Vous pouvez imaginer les ingénieurs qui ont construit le système en pensant « si le pilote automatique se désengage, c'est probablement parce qu'il y a une situation où les pilotes pourraient avoir besoin d'un contrôle supplémentaire ! ”

C'est le courant de pensée naturel des ingénieurs, qui comprennent quels types de choses peuvent provoquer le désengagement du pilote automatique. Pour les pilotes, ce n'était pas le cas. Ils ont forcé l'avion à effectuer une montée abrupte, ignorant les avertissements "STALL", jusqu'à ce qu'il perde toute vitesse et s'effondre dans l'océan. Les 228 passagers et membres d'équipage ont été tués. Bien qu'il existe plusieurs idées quant à la motivation exacte de leurs actions, la théorie dominante est que les pilotes ont supposé que l'ordinateur de vol empêcherait les entrées de commande qui feraient caler l'avion (ce qui est vrai pour le domaine de vol normal), et n'ont pas réalisé que il était passé au mode d'enveloppe étendue parce qu'ils ne partageaient pas le modèle mental des ingénieurs de la logique qui guidait les décisions de l'ordinateur.

Bien qu'il s'agisse d'un chemin un peu détourné, cela nous amène à mon point principal : les actions que vous souhaitez que les utilisateurs entreprennent dans des conditions spécifiques doivent être les actions qui semblent naturelles à l'utilisateur .

Les utilisateurs peuvent être invités à suivre des procédures spécifiques, mais ils ne se souviendront tout simplement pas toujours de la bonne chose à faire ou ne comprendront pas ce qui se passe dans des conditions de stress élevé. Il est de votre responsabilité de concevoir des logiciels, des contrôles et des interfaces d'une manière intuitive qui incite les utilisateurs à vouloir faire ce qu'ils sont censés faire.

Cela signifie qu'il est absolument essentiel que les utilisateurs finaux participent à chaque étape du processus de conception et de développement. Il ne peut y avoir aucune hypothèse sur ce que les utilisateurs feront probablement ; tout doit être fondé sur des preuves. Lorsque vous concevez des interfaces, vous devez mener des études pour déterminer les schémas de pensée qu'elles induisent chez les utilisateurs et les ajuster si nécessaire. Lorsque vous testez vos nouveaux systèmes, vous devez les tester avec de vrais utilisateurs dans des environnements réels dans des conditions réalistes. Et malheureusement, lorsque vous modifiez vos conceptions, vous devez recommencer ces étapes.

Bien que chaque système complexe soit unique, j'aimerais mentionner trois considérations de conception, en particulier, qui devraient être appliquées universellement :

• Les contrôles doivent être représentatifs des actions qu'ils invoquent. Heureusement, celui-ci est assez courant, généralement vu sous la forme de sélection d'icônes pertinentes pour les boutons de l'interface graphique ou de formes pertinentes pour les commandes physiques. Les boutons "Nouveau fichier" utilisent une icône de feuille de papier vierge, et les leviers de train d'atterrissage des avions ont un bouton en forme de roue. Cependant, il est facile de devenir complaisant. Pourquoi voyons-nous encore des icônes de disquettes 3,5" pour les boutons "Enregistrer" ? Est-ce que quelqu'un de moins de 25 ans sait ce qu'est une disquette ? Nous continuons à l'utiliser parce que nous pensons qu'il est représentatif, mais ce n'est vraiment plus le cas. Cela nécessite un effort constant pour s'assurer que les représentations des contrôles sont significatives pour les utilisateurs, mais il est également nécessaire et difficile d'équilibrer cela avec la continuité.
• Si un système d'alerte tombe en panne, il doit être détectable. Nous utilisons souvent des voyants d'avertissement qui s'activent en cas de problème, comme un indicateur rouge clignotant. C'est génial pour attirer l'attention d'un utilisateur, mais que se passe-t-il si la lumière s'éteint ? Le vaisseau spatial utilisé dans les missions lunaires Apollo avait des dizaines de voyants d'avertissement pour toutes sortes de systèmes, mais ils ne fonctionnaient pas de manière conventionnelle. Au lieu de s'allumer quand il y avait un problème, ils restaient allumés quand tout allait bien et s'éteignaient quand il y avait un problème. Cela garantissait qu'un voyant d'avertissement grillé ne ferait pas manquer aux astronautes une erreur système potentiellement fatale. Je ne dis pas que vous devriez utiliser cette conception, car les ampoules ont parcouru un long chemin en termes de fiabilité depuis les années 1960, mais cela donne une idée de la profondeur de votre planification. Combien de fois un système est-il tombé en panne sans que vous le sachiez, car la journalisation ou les notifications ne fonctionnaient pas correctement ?
• Les transitions de mode doivent être évidentes pour l'utilisateur. Que se passe-t-il si un Airbus A330 passe du mode de contrôle normal au mode de contrôle avancé sans que l'utilisateur ne s'en aperçoive, et que soudainement l'avion fait des choses que l'utilisateur ne pensait pas pouvoir faire ? Que se passe-t-il si une voiture autonome désengage son pilote automatique, laissant l'utilisateur en plein contrôle de manière inattendue ? Que se passe-t-il lorsqu'il y a une transition majeure dans le mode ou la fonctionnalité qui nécessite un changement immédiat dans les actions de l'utilisateur, mais qu'il faut une minute ou deux à l'utilisateur pour comprendre ce qui vient de se passer ? Bien qu'une variété de modes de fonctionnement puisse être nécessaire dans un système complexe, les modes ne peuvent pas passer sans un préavis, une explication et une interaction adéquats avec l'utilisateur.

Déploiement des systèmes vitaux hors de l'atelier

Conformément aux meilleures pratiques de l'industrie, une phase bêta est cruciale pour les déploiements de nouveaux systèmes vitaux. Les tests de votre nouvelle technologie vous ont peut-être aidé à corriger la majorité des bogues et des problèmes d'utilisation, mais des dangers cachés peuvent apparaître lorsqu'elle doit être utilisée avec d'autres systèmes dans des environnements réels. Dans la discipline de l'ingénierie des systèmes, c'est ce qu'on appelle «l'émergence». Les propriétés émergentes sont des « comportements inattendus qui découlent de l'interaction entre les composants d'une application et leur environnement » et, de par leur nature même, sont essentiellement impossibles à détecter en laboratoire. En invitant un groupe représentatif d'utilisateurs finaux à tester votre nouveau système sous une surveillance attentive, bon nombre de ces propriétés peuvent être détectées et évaluées pour les conséquences négatives qui peuvent apparaître lors d'un déploiement à grande échelle.

Un autre sujet qui revient souvent dans les discussions d'architecture avec mes clients est celui d'un déploiement progressif. C'est le choix entre remplacer progressivement les éléments d'un système préexistant par des éléments d'un nouveau jusqu'à ce que tout soit finalement remplacé ou tout changer en même temps. Il y a des avantages et des inconvénients pour chacun : un déploiement progressif permet une acclimatation progressive des utilisateurs à la nouvelle conception, garantissant que les changements arrivent en quantités gérables et que les utilisateurs ne sont pas submergés ; d'autre part, cela peut faire traîner le processus sur de longues périodes et aboutir à un état de transition constant. Les déploiements immédiats sont bénéfiques dans la mesure où ils "arrachent le pansement" et accélèrent les choses, mais les changements drastiques soudains peuvent submerger les utilisateurs.

Pour les systèmes vitaux, j'ai constaté que les déploiements progressifs sont généralement plus sûrs, car ils permettent une évaluation incrémentielle des composants individuels dans un environnement de production et permettent des inversions plus petites si quelque chose doit être annulé. C'est quelque chose qui doit être évalué au cas par cas, cependant.

Normalisation de la déviance

OK, donc vos tests utilisateurs vous ont aidé à concevoir un système intuitif, votre phase bêta a identifié les problèmes émergents, votre déploiement progressif a permis aux utilisateurs de se familiariser avec la conception et tout se passe bien. Vous avez terminé, n'est-ce pas ? Malheureusement non.

Des problèmes avec votre système surgiront inévitablement, il n'y a pas moyen de contourner cela. Lorsque les utilisateurs rencontrent ces problèmes, ils développent souvent des solutions de contournement au lieu de signaler le problème à l'équipe technique. Les solutions de contournement deviendront une pratique standard, partagées sous forme de «conseils» des vétérans aux recrues. La sociologue Diane Vaughan a inventé une expression pour décrire ce phénomène : « normalisation de la déviance ». Les utilisateurs s'habituent tellement à un comportement déviant qu'ils ne se souviennent pas qu'il s'agit en fait d'un comportement déviant.

L'exemple classique est la navette spatiale Challenger : on a régulièrement observé qu'un composant des propulseurs de fusée à solide s'érodait pendant le lancement, et bien que tout le monde sache que l'érosion des composants de la fusée était une mauvaise chose, cela arrivait si souvent que des dérogations étaient régulièrement émises et il a été considéré Ordinaire. Le 28 janvier 1986, le problème que tout le monde savait à l'origine ne devrait pas être autorisé, mais qu'ils avaient normalisé, a entraîné l'explosion de Challenger et la mort de sept astronautes.

En tant qu'administrateur d'un système vital, il vous appartient d'empêcher que de tels événements ne se produisent. Étudiez comment vos utilisateurs interagissent avec le système. Observez-les pendant quelques jours et voyez s'ils utilisent des solutions de contournement inattendues. Envoyez périodiquement des sondages pour demander des suggestions de modifications et d'améliorations. Consacrez du temps et des efforts à l'amélioration de votre système avant que vos utilisateurs ne trouvent des moyens de contourner les problèmes sans vous.

Entraînement pour la performance sous pression

Il arrive souvent que des défaillances dans les systèmes vitaux se produisent lorsque les utilisateurs souffrent de stress, de montées d'adrénaline et d'une vision en tunnel. C'est arrivé aux pilotes d'Air France 447, c'est arrivé aux ambulanciers qui ne se souviennent plus comment faire fonctionner leur moniteur cardiaque sur leur premier patient en arrêt cardiaque, et c'est arrivé aux soldats qui ne peuvent pas faire fonctionner correctement leurs radios sous le feu.

Une partie de ce risque est atténuée par l'utilisation de conceptions intuitives, comme indiqué précédemment, mais cela seul est insuffisant. En particulier dans les environnements où des scénarios de stress élevé se produisent mais se produisent rarement, il est essentiel de former vos utilisateurs non seulement à l'utilisation de votre système, mais également à la manière de penser clairement dans de telles conditions. Si les utilisateurs mémorisent des actions relatives à l'exploitation des équipements, ils ne peuvent pas faire face à des pannes inattendues car les actions qu'ils ont apprises peuvent ne plus être appropriées ; S'ils s'entraînent à penser logiquement et clairement en cas de stress, ils peuvent réagir aux circonstances changeantes et aider votre système à rester en vie lorsque quelque chose se brise.

Conclusion

De toute évidence, le développement, le déploiement et la maintenance de logiciels vitaux sont bien plus complexes que ce qui peut être détaillé dans un seul article. Cependant, ces domaines de considération peuvent vous donner une meilleure idée de ce à quoi vous attendre lorsque vous envisagez de travailler sur un tel projet. En résumé:

• L'innovation est nécessaire, même quand tout fonctionne bien
• Il est difficile de convaincre les dirigeants que le risque en vaut la peine, mais les chiffres ne mentent pas
• Les utilisateurs finaux doivent être impliqués à chaque étape du processus
• Testez et retestez avec de vrais utilisateurs dans des environnements réels dans des conditions réalistes
• Ne présumez pas que vous avez bien compris la première fois ; même si cela fonctionne, il peut y avoir des problèmes non détectés dont vos utilisateurs ne vous parlent pas.
• Formez vos utilisateurs non seulement sur la façon d'utiliser le système, mais aussi sur la façon de penser clairement et de s'adapter au stress.

En conclusion, j'aimerais noter que dans les systèmes complexes critiques pour la sécurité, les choses vont mal à un moment donné, quelle que soit la planification, les tests et la maintenance que vous effectuez. Lorsque ces systèmes sont vitaux, il est tout à fait possible qu'une défaillance puisse entraîner la mort ou la perte d'un membre.

Dans le cas où une telle tragédie se produirait avec quelque chose dont vous êtes responsable, ce sera un poids écrasant sur votre conscience et vous penserez probablement que vous auriez pu l'empêcher si vous aviez fait plus attention ou travaillé plus fort. C'est peut-être vrai, peut-être que non, mais il est impossible de prévoir tous les événements possibles.

Travaillez méticuleusement, ne soyez pas arrogant et vous rendrez le monde meilleur.