Cumulant plus de 40 ans d’expérience en normalisation, Jean Bérubé a participé aux travaux de dizaines de comités et a vu évoluer les normes sur la gestion de systèmes et les technologies de l’information et de la communication. Son travail à la direction de comités canadiens, dont plus de 25 ans en tant que chef de la délégation canadienne du comité technique mixte 1de l’Organisation internationale de normalisation et du sous-comité 7 de la Commission électrotechnique internationale (ISO/IEC JTC 1/SC 7 – Ingénierie du logiciel et des systèmes), a profité énormément au pays et au système international de normalisation. À la fin de 2018, le Conseil canadien des normes (CCN) a remis à M. Bérubé un certificat de reconnaissance et en a profité pour parler avec lui de son impressionnante carrière et de l’importance des normes.
Vous évoluez depuis longtemps dans le monde international de la normalisation. Qu’est-ce qui vous a incité à choisir ce domaine?
Tout a commencé quand j’ai lu dans une revue professionnelle – je crois que c’était Computer World – que le CCN cherchait quelqu’un pour travailler sur une norme relative au langage de programmation PL/I. C’était en 1976. Comme j’étais propriétaire de l’une des rares entreprises spécialisées en langage PL/I à Montréal, j’ai répondu à l’appel.
À ma première réunion du comité de normalisation, j’ai été impressionné par la manière dont le président du groupe du langage de programmation – à l’époque, c’était Robert Kearney – gérait la réunion. J’estime avoir décroché le gros lot. Robert a fini par devenir président de Bell Canada, preuve de son talent naturel. C’est ce qui m’a convaincu d’embarquer : j’ai trouvé le comité bien organisé, et le sujet, intéressant.
Le domaine me captivait, et j’ai constaté l’efficacité des normes pour acquérir et transmettre des connaissances. Les réunions de normalisation se comparaient, pour moi, à des conférences ou à des séminaires. Mon cerveau fonctionnait à plein régime pendant une semaine; je discutais avec des gens qui avaient de bonnes idées et qui – le plus souvent – me surpassaient en intelligence et était doués d’une grande éloquence.
Le choix des comités auxquels j’ai participé était motivé non seulement par mes centres d’intérêt, mais aussi par mes activités professionnelles du moment. J’ai été à l’emploi d’une compagnie d’assurance jusqu’en 1980. Ensuite, j’ai été consultant pour un cabinet-conseil jusqu’en 1990, pour ensuite me lancer à mon compte. J’ai connu beaucoup de succès, et ma contribution au milieu de la normalisation y est pour quelque chose.
J’ai aussi touché à l’administration et à la gestion dans le domaine. J’ai toujours aimé aider les autres à s’organiser et leur faciliter la tâche.
Pourquoi la normalisation est-elle si importante?
Il va sans dire que les normes sont en soi importantes, et que bien des raisons peuvent attirer quelqu’un dans ce milieu. À mon sens, la norme stipule quelque chose qui fait consensus, et les deux volets – les stipulations et le consensus – me plaisent.
Ce n’est pas la même optique que chez les professeurs d’université, par exemple. Quand ces experts publient un article, ils doivent décrire un nouveau concept et se démarquer de leurs confrères et consœurs. S’ils se contentent d’abonder dans leur sens, ils n’iront nulle part. Ils doivent s’opposer. La même logique vaut pour les produits commerciaux : les entreprises vendent des produits qui sont le fruit de leur travail, et non d’un consensus. Quant aux normes, elles sont l’aboutissement d’un consensus obligé, et me paraissent donc, d’une certaine façon, plus fiables.
Les normes sont importantes aux égards normalement reconnus – la fiabilité, l’interopérabilité, la protection des consommateurs et le commerce –, mais le volet savoir m’intéresse plus que le volet certification. Au départ, j’ai travaillé sur la normalisation de choses, comme des langages de programmation. En revanche, les normes qui concernent un processus – comme une norme qui énonce les critères à satisfaire avant d’écrire la première ligne de code – seront ultimement suivies par un être humain. Or, nous sommes passablement plus difficiles à programmer qu’un ordinateur!
La plupart des normes du SC 7 définissent des processus, mais nous en avons aussi sur les ressources humaines, comme la qualification des ingénieurs de systèmes. Ces normes font leur chemin, lentement mais sûrement, dans les cursus universitaires, vu les particularités du génie des systèmes et du logiciel, enseigné dans très peu de facultés. En génie civil, les étapes de la construction d’un pont sont enseignées à l’université, et les normes sur le béton, par exemple, sont bien établies. Le portrait est tout autre dans le génie des systèmes et du logiciel; notre discipline est nouvelle, et nous apprenons sur le tas.
Comment votre contribution s’est-elle élargie à autant de comités différents au fil de vos 40 ans de carrière?
J’ai l’air de faire la tournée des comités, mais mes activités ont bel et bien un fil directeur.
Comme je l’ai déjà dit, ma carrière en normalisation a débuté en 1976 avec les langages de programmation. Il y a d’abord eu PL/I, puis Ada (un autre langage). J’ai ensuite travaillé sur les systèmes d’exploitation et les langages de commande, encore dans le domaine des langages.
Par après, j’ai découvert un comité voué aux langages de base de données et à la gestion de données, qu’on appelle aujourd’hui le SC 32 [ISO/IEC JTC 1/SC 32 – Gestion et échange de données]. En génie des systèmes logiciels, la mise au point d’un système implique la création d’un langage de programmation, lui-même assorti de bases de données. J’ai constaté non seulement que les normes sur la gestion de données sont liées aux langages de base de données, mais aussi qu’on élabore des normes sur les métadonnées pour les dictionnaires et d’autres éléments rattachés aux systèmes. C’est ainsi que j’ai commencé à explorer le sujet, en 1986, et je suis resté actif dans ce groupe pendant une dizaine d’années, jusqu’en 1997. C’était complémentaire à ce que je faisais au SC 7 du côté des langages de modélisation.
Quand le JTC 1 a vu le jour, je me suis joint au SC 7, qui était plus proche de ce que je faisais à l’époque comme consultant pour une entreprise vendant des méthodes et des outils de développement de systèmes. Durant cette période, le SC 7 est passé de quatre normes à plus d’une centaine. Il se caractérise notamment par sa grande collaboration avec d’autres groupes et consortiums, dont l’IEEE, l’OMG, l’UIT et l’INCOSE.
J’ai aussi surveillé de nombreux autres groupes. Par exemple, la gestion des systèmes appartenait à un groupe de travail du SC 7, avant d’être confiée à un sous-comité distinct, le SC 40 [ISO/IEC JTC 1/SC 40 – Gestion des services IT et gouvernance IT]. Cependant, au SC 7, comme nous étions déjà en train d’élaborer des normes sur la prestation de services, j’ai fait le pont. La même chose s’est produite avec le SC 38 [ISO/IEC JTC 1/SC 38 – Plateformes et services d’applications distribuées] : j’ai continué de surveiller ce comité en raison de ses travaux axés sur l’architecture orientée sur les services et la portabilité, des points qui se rapportaient à ma pratique. Cela dit, dans ces groupes, mes interventions se limitaient essentiellement à fournir un suivi et des commentaires.
Enfin, mes fonctions actuelles à l’Agence des services frontaliers du Canada – à titre d’architecte d’entreprise en sécurité et en protection des renseignements personnels – m’ont amené à m’intéresser aux normes en la matière, si bien que je me suis inscrit à quelques comités. Je deviendrai probablement plus actif dans cette sphère quand elle me sera plus familière.
Voilà qui résume mes activités de normalisation, mais je me suis aussi frotté à la gestion : en 1987, je suis devenu président du comité parallèle canadien du SC 7, trois mois après la constitution du groupe.
Pour être franc, ça m’a plu. En début de carrière, j’ai eu le choix entre la gestion et le travail technique, et j’ai opté pour le second. Cependant, l’expérience que j’ai acquise en faisant de la gestion en normalisation a été utile : il s’agit non pas d’exercer une autorité officielle, mais d’user de persuasion. Il faut gérer des projets avec des bénévoles, et je me suis aperçu que, la plupart du temps, il m’était plus facile de mobiliser des bénévoles que mes propres employés, grâce à leur niveau d’intérêt plus élevé. J’ai aussi pu apprendre à faire bouger les choses dans ce contexte.
J’aime aussi l’administration. Je suis de ces gens bizarres qui aiment ranger des bibliothèques, classer des documents et produire des modèles pour uniformiser la production de documents. Il n’est donc pas surprenant que je sois devenu secrétaire dans bon nombre des groupes dont j’ai fait partie, ou que j’aie créé des systèmes pour ensuite les confier au secrétaire. Évidemment, tout le monde trouve la structure et l’organisation de mes sites excessives, mais je ne me suis jamais plaint du recours à SiteScape ou à un système de bibliothèques.
Parmi les facettes du rôle de secrétaire, j’aime aussi le pouvoir que sous-tend la rédaction des procès-verbaux : on reste à l’affut de tout ce qui se passe, et on peut organiser les choses avec clarté pour que chacun sache ce qu’il a à faire.
Qu’avez-vous tiré de votre contribution à la normalisation internationale?
En faisant de la gestion, j’ai appris des choses qui me seraient restées étrangères autrement, comme composer avec la politique et dégager des consensus. Dans le milieu de la normalisation, le Canada est généralement une sorte de négociateur. Dans mon temps, la conciliation se faisait entre les États-Unis et le Royaume-Uni. Nous cherchons des terrains d’entente et veillons à ce que les travaux puissent cheminer. Il m’a fallu jouer ce rôle au SC 7, parce que le groupe comptait de très grands producteurs de logiciels et des clients tout aussi importants, y compris des ministères et des organismes gouvernementaux.
Le Canada est-il souvent appelé à concilier des parties aux vues différentes (et parfois opposées) dans des forums internationaux de normalisation?
Oui, et on peut presque dire que c’est maintenant attendu de nous. J’ai observé le phénomène dans tous les comités. Le Canada est vu comme une partie neutre et non menaçante. Nous avions peu d’intérêts commerciaux dans certains champs, ce qui faisait de nous un négociateur de confiance. C’est intéressant, car on peut en tirer une satisfaction que ne procure pas toujours la rédaction technique. Le sentiment d’accomplissement est plus immédiat. La plénière s’ouvre avec un conflit à l’horizon, mais une solution pacifique intervient avant la clôture (et dure au moins six mois).
Pouvez-vous me raconter un fait saillant de votre carrière en normalisation?
Le tout premier remonte à 2006, année où le CCN a récompensé son comité parallèle du SC 7 lors d’un souper-gala au Musée des beaux-arts du Canada. Je pense aussi à la mise en place des profils, soit des documents normalisés qui rassemblent du matériel provenant de plusieurs autres normes dans un but précis et qui procurent des avantages semblables à ceux des normes. Je commencerai par dire que les normes du SC 7 tendent à être très lourdes. En général, les petites organisations comme celle qui m’employait s’en passent. Les très petites entreprises et les équipes chargées d’un très petit projet au sein d’une grande entreprise, ne pouvant pas utiliser ces normes volumineuses, en venaient à improviser leur propre cycle de vie de développement de systèmes. Mais le Canada a joué un rôle déterminant, en 2004-2005, en rendant le contenu des normes du SC 7 plus accessible. En fait, on peut attribuer la paternité de ces améliorations à Anatol Kark, qui a animé les comités des normes 12207 (ISO/IEC 12207 – Ingénierie des systèmes et du logiciel – Processus du cycle de vie du logiciel) et 15288 (ISO/IEC/IEEE 15288:2015 – Ingénierie des systèmes et du logiciel – Processus du cycle de vie du système), et en est maintenant le secrétaire.
Au départ, nous avons organisé une réunion à Brisbane pour discuter de la possibilité de condenser la norme 12207 dans un souci d’accessibilité, et nous avons eu droit à deux réactions. La première provenait de son auteur, qui estimait une mise en œuvre partielle impossible. Il soutenait que le document ne pouvait être réduit à une vingtaine de pages et nous a demandé de ne pas y toucher. Nous avons donc décidé de former un autre groupe.
L’autre réaction était celle de représentants de la Thaïlande, qui ont dit : « Eh bien, nous avons commencé à le faire; comme la norme 12207 est modulable, nous en avons pris une partie, que nous avons publiée en tant que norme nationale. Les résultats sont là, et nous sommes prêts à affecter des fonds ». Une alliance s’est donc formée entre le Canada et la Thaïlande, à qui est revenue l’animation du groupe. J’en ai été le secrétaire, car j’avais de l’expérience en organisation et pouvais remplacer l’animateur pendant qu’il était en formation. En Thaïlande, nous avons convié un panel d’experts à trois réunions pour préparer le cahier des charges du projet et les documents requis, et nous avons sondé les clients. Nous avons alors découvert que le Mexique avait fait des démarches équivalentes en se dotant d’une norme nationale, qui avait cependant une échelle un peu plus grande et ciblait les PME plutôt que les très petites entreprises. La taille de cette norme nationale ressemblait à celle que nous visions. Par conséquent, le Mexique l’a traduite en anglais, puis nous a fourni le matériel qui devait nous servir de document de base. Nous avons créé une série de documents (20) sous le grand projet 29110.
Si j’ai d’abord fait de la gestion et du soutien administratif, le sujet lui-même a fini par me passionner. L’un de mes bons coups a été la découverte d’un document obscur d’interconnexion des systèmes ouverts (OSI – Open Systems Interconnection) sur la création de profils, un moyen méthodique de prendre des éléments d’autres normes pour en faire un document normalisé. J’ai ensuite convaincu tout le monde que cette option était la meilleure en invoquant qu’elle nous permettait de partir de la norme originale et d’incorporer des exigences contenues dans l’un ou l’autre des normes du SC 7. Cette méthode nous a permis de produire un document intégré et succinct qui énonçait les exigences en matière de processus, d’outils, de ressources et de compétences. À ce jour, le succès de ce projet ne se dément pas.
À quoi ressemblerait le monde aujourd’hui sans votre travail et celui des comités auxquels vous avez siégé? Qu’ont apporté les normes dans les divers domaines?
Les effets sur le monde réel sont difficiles à déterminer. La plupart de nos normes servent de documents de référence et ne sont pas nécessairement mises en œuvre telles quelles. Elles constituent une base de référence en génie des systèmes et du logiciel, aidant les organisations à adopter les pratiques standard. Vu la nature de ses normes qui concernent les processus, le SC 7 a dû mettre au point une méthode normalisée d’évaluation des processus, axée plus sur les résultats et l’évaluation des capacités que sur la conformité à des exigences.
Cela dit, de nouvelles façons de cacher ces éléments dans des outils apparaissent, et nous commençons à voir quelques-unes de nos normes imbriquées dans des outils de gestion de projet ou d’établissement de plans de travail. Les méthodes de développement de systèmes étant des processus opérationnels, elles peuvent être intégrées à un outil de processus opérationnels et livrées à même l’outil. Nos normes prendront probablement cette forme à l’avenir, c’est-à-dire des spécifications à insérer dans des outils de flux de production ou de gestion de projets. C’est comme ça que s’y prennent les entreprises pour réussir.
Avez-vous des conseils ou des idées pour ceux qui songent à contribuer activement à la normalisation? Qu’est-ce que les jeunes professionnels ont à y gagner?
Outre la satisfaction d’être un maillon du monde de la normalisation, bien sûr, les participants ont accès à un riche et vaste bassin de connaissances. De plus, on y gagne en rigueur et en discipline dans la préparation de livrables, et on y apprend à négocier pour arriver à des consensus. Voilà ce que j’en ai tiré, et j’estime que c’est un bon argument de vente.
Quand j’explique à quelqu’un pourquoi il devrait se joindre au groupe, je lui dis qu’on reçoit autant qu’on donne, voire plus. Le participant ou la participante n’est pas rémunéré, mais en profite à d’autres égards. Pour ma part, je me suis fait des contacts et des amis, j’ai tiré des avantages sur le plan du marketing et j’ai décroché des contrats par l’entremise de personnes rencontrées dans le milieu de la normalisation. Ce ne sont pas les motifs valables qui manquent pour consacrer quelques semaines par année aux travaux d’un comité.