Normaliser les systèmes, pas les humains

En janvier 1994, j’assistais à une conférence NEXTSTEP à Washington. Parmi les conférenciers figurait Paul Strassmann, ancien directeur de l’information de la Défense américaine. Le programme conservé dans les archives situe son intervention le 26 janvier, au Sheraton Washington.¹

Je me souviens très clairement de son propos. Il présentait le champ de bataille comme une activité d’une complexité extrême : des décisions de vie ou de mort, un adversaire potentiellement aussi capable que soi, et un flot d’informations provenant de satellites, de caméras, de communications et de capteurs. Dans cet environnement, accumuler davantage de données ne suffisait pas. Il fallait arriver à repérer, au bon moment, celles qui avaient une signification pour la personne appelée à agir.

L’exemple qu’il avait choisi m’avait frappée : HyperCard. Dans une conférence consacrée à NeXT, il citait cet outil d’Apple pour expliquer comment un utilisateur pouvait rapidement définir des conditions et être averti lorsqu’une situation pertinente se présentait. Je rapporte ici mon souvenir de cette intervention, à laquelle j’ai assisté, et non une transcription de ses paroles.

J’avais moi-même accueilli HyperCard avec enthousiasme à sa sortie, en 1987.² Il ouvrait une possibilité qui me semblait essentielle : permettre à des personnes qui n’étaient pas programmeuses de fabriquer de petites applications. Il fallait apprendre certaines choses et accepter des limites, mais on pouvait déjà modeler son outil autour de son besoin.

Ce souvenir m’est revenu en réfléchissant à ce que l’IA permet aujourd’hui. Puisqu’il devient plus accessible de créer des logiciels sur mesure, pourquoi une organisation ne permettrait-elle pas à ses employés de concevoir des applications adaptées à leur façon de travailler, à condition de respecter ses règles et ses mécanismes d’échange d’information ?

Dans « Le logiciel avant la décision », j’explorais ce que la baisse du coût d’essayer change à la création d’un logiciel. La même évolution pourrait transformer la manière dont une organisation accueille les méthodes de ses employés. La question dépasse le confort d’utilisation : elle touche à la place que nous accordons à la contribution individuelle.

Ce qui doit être commun

Il faut d’abord distinguer deux ambitions souvent confondues. Une organisation peut normaliser les données, les règles, les contrôles et les échanges nécessaires à son fonctionnement collectif, sans imposer à tout le monde la même interface ni la même méthode de travail. Ce socle commun soutient la cohérence, la sécurité, la traçabilité et l’équité. Les outils et les méthodes peuvent laisser place à l’expérience, aux capacités et aux contextes de chaque personne.

Dans beaucoup d’organisations, le logiciel définit une bonne partie du parcours de travail : les écrans à consulter, l’ordre des opérations, les informations mises en évidence. Cette uniformité a des avantages réels. Elle facilite la formation, le soutien technique et la continuité lorsqu’un dossier passe d’une personne à une autre. Certains gestes doivent aussi suivre un ordre précis pour garantir la qualité ou l’équité d’un traitement.

Mais une interface commune fait également des choix pour tout le monde. Elle privilégie une façon de comprendre un dossier et d’organiser son attention. Ce qui convient à une personne peut ralentir une autre, même lorsque les deux accomplissent un excellent travail.

L’une commence par reconstruire la chronologie. Une autre compare quelques indicateurs. Une troisième repère d’abord les exceptions et remonte ensuite vers leurs causes. Ces différences peuvent exprimer une expérience, une aptitude ou une méthode qui mérite d’être conservée.

Nous avons souvent accepté de les comprimer pour des raisons pratiques. Développer et maintenir de nombreuses variantes d’un logiciel coûtait cher. L’interface commune constituait un compromis raisonnable. Avec le temps, cependant, ce compromis peut devenir une conception implicite du travail : si tout le monde utilise le même système, tout le monde devrait procéder de la même manière.

Des outils à la mesure du travail

L’IA ouvre la possibilité de réexaminer ce choix. Des outils permettent déjà de décrire une application en langage courant, d’en obtenir une première version et de la modifier par échanges successifs.³ Cela ne rend pas automatiquement le résultat fiable, mais abaisse la barrière entre un besoin précis et un outil que l’on peut essayer.

Imaginons une employée qui souhaite retrouver, dès l’ouverture d’un dossier, les quatre informations qu’elle consulte systématiquement et les trois dernières interactions. Elle voudrait aussi être avertie lorsqu’une modification survient après une étape importante. Sa collègue préfère une vue chronologique qui met les contradictions en évidence. Une troisième a besoin d’une présentation plus sobre, adaptée à ses besoins d’accessibilité.

Elles pourraient travailler sur les mêmes dossiers, avec les mêmes permissions, les mêmes données de référence et les mêmes obligations, à travers des environnements différents. L’organisation conserverait une définition commune de ce qui constitue un dossier complet et un traitement valide. Chacune disposerait d’une manière plus naturelle d’y parvenir.

Pour rendre cette liberté possible, les règles et les contrôles essentiels doivent être appliqués par les services de l’organisation, quel que soit l’écran utilisé. Les interfaces de programmation — les API — donnent accès à ces services selon des conditions définies. Les applications personnelles peuvent alors organiser les vues, les filtres, les alertes et certaines séquences de travail à l’intérieur de ce cadre.

On pourrait ainsi choisir comment présenter une information, tout en conservant sa définition commune. On pourrait ajouter ses propres alertes et en définir les conditions, tout en maintenant les alertes obligatoires. On pourrait organiser son parcours à condition de respecter les étapes et les contrôles nécessaires au traitement du dossier.

Respecter le format d’une API ne suffit donc pas. Un outil peut échanger des données correctement et présenter une information trompeuse, masquer une exception ou déclencher une opération au mauvais moment. Chaque application devrait être vérifiée en fonction de ce qu’elle présente et des actions qu’elle permet.

Moderniser sans tout reconstruire

Cette architecture offre aussi une perspective intéressante pour les systèmes existants. Un ordinateur central peut continuer à exécuter ses transactions pendant que de nouvelles interfaces donnent accès à ses fonctions. Des solutions comme IBM z/OS Connect permettent déjà d’exposer des applications et des données de mainframe au moyen d’API.⁴

Cela ne signifie pas que tous les systèmes anciens peuvent rester intacts. Certains exigent un travail important pour rendre leurs fonctions accessibles, dissocier les règles métier des écrans ou renforcer les contrôles. Mais moderniser l’expérience de travail n’impose pas nécessairement de réécrire tout le cœur transactionnel. On peut préserver ce qui fonctionne et investir dans la possibilité de l’utiliser autrement.

Le coût de création d’un écran n’est d’ailleurs qu’une partie du problème. Il faut encore tester, maintenir, soutenir les utilisateurs et adapter les outils lorsque les services communs évoluent. Une organisation aurait intérêt à fournir des composants approuvés, un environnement d’essai et des mécanismes de vérification partagés. Une vue personnelle en lecture seule n’exige pas le même encadrement qu’une application autorisant des paiements.

Les équipes informatiques auraient ici un rôle déterminant : construire un cadre dans lequel cette autonomie devient praticable. Elles pourraient consacrer davantage d’efforts à la qualité des services communs et accompagner les employés dans la création d’outils fiables. Une interface de référence resterait disponible pour la formation, le soutien et les personnes qui la préfèrent. Personnaliser son environnement devrait être une possibilité, jamais une obligation supplémentaire.

Faire circuler les méthodes

Ce qui m’intéresse surtout, c’est ce qu’une telle liberté pourrait faire apparaître.

Une employée expérimentée sait parfois reconnaître une situation inhabituelle à partir de quelques indices difficiles à traduire en procédure générale. En construisant un outil qui rapproche ces indices, elle rendrait une partie de sa méthode visible et discutable. Ses collègues pourraient l’essayer, découvrir ses limites, l’adapter à leur pratique. L’organisation disposerait alors d’un moyen supplémentaire de faire circuler l’expérience.

Il faudrait résister à la tentation de transformer immédiatement toute bonne idée en nouvelle norme obligatoire. Une méthode peut être excellente pour certaines tâches ou certaines personnes sans convenir à toutes. Sa valeur se jugerait sur la qualité du travail, les erreurs évitées, la coopération et le service rendu, au-delà du seul nombre de dossiers traités.

Cette possibilité de façonner ses outils n’a jamais complètement disparu. Les tableurs, les macros et les petites bases de données en témoignent. Mais ces initiatives restent souvent fragiles, dépendantes d’une seule personne ou difficiles à intégrer aux systèmes officiels. L’IA pourrait élargir cette capacité de création et permettre de l’inscrire dans un cadre partagé.

Une possibilité à choisir

En revisitant les travaux de Strassmann, j’ai retrouvé un écho à cette idée. Un mémoire de Charles D. Miller publié en 1993 rapporte son concept de Shadow Warrior : un logiciel personnel qui reconnaîtrait les habitudes de son utilisateur et l’aiderait à composer avec ses limites de traitement de l’information. Le même document évoque aussi un affichage standard destiné à faciliter la formation. Ces deux objectifs — continuité collective et adaptation individuelle — étaient donc déjà présents dans la réflexion de l’époque.⁵

Trente-deux ans après cette conférence de Washington, je retrouve l’enthousiasme qu’HyperCard avait suscité chez moi. L’IA pourrait donner une portée nouvelle à cette capacité de fabriquer l’outil dont on a besoin. Son intérêt tient autant à la diversité des usages qu’elle rend possibles qu’à la vitesse de production du code.

Rien ne garantit que les organisations choisiront cette direction. Elles pourraient utiliser les mêmes technologies pour prescrire chaque geste avec davantage de précision. Elles pourraient aussi reconnaître qu’une partie de leur intelligence réside dans les différentes façons dont leurs employés comprennent leur travail.

Normaliser les systèmes, pas les humains : ce serait donner à cette diversité une place légitime dans notre informatique, avec la cohérence nécessaire au travail collectif. Et faire de l’IA un moyen d’accroître la contribution particulière de chacun.

Références