Chercheurs et ingénieurs en informatique

Nécessaire (mais difficile) alliance

Laurent Bloch
 

Le beau métier d'ingénieur

   Le premier Spoutnik a été mis sur orbite le 4 octobre 1957, quelques jours avant mon dixième anniversaire : cet événement et ses suites ont enthousiasmé mon enfance et mon adolescence, je rêvais d'être ingénieur pour concevoir et fabriquer des fusées et des avions, d'entrer à Sup'aéro. Je n'ai jamais obtenu de titre officiel d'ingénieur, mais en fait c'est le métier que j'ai fait toute ma vie, pas dans l'aéronautique, mais en informatique. Je pensais (et je continue à penser) que c'est un des plus beaux métiers du monde (pour savoir ce qu'il en advient, on pourra se reporter à un excellent article d'un blog des Échos [1].

   Vingt-quatre ans plus tard, le premier septembre 1981, je suis devenu chef du service informatique de l'Institut national d'études démographiques (INED) [2], et là j'ai découvert un autre métier dont à vrai dire j'ignorais tout : chercheur. Et, pendant les trente années qui ont suivi, j'ai travaillé avec des chercheurs, au Cnam, à l'Institut Pasteur, à l'Inserm, à l'Université Paris-Dauphine.

   Le travail de l'ingénieur consiste à concevoir des choses réalisables avec les moyens dont il dispose (ou qu'il peut créer), et à les réaliser. Le travail du chercheur consiste à concevoir des choses ou des idées nouvelles, dont on ignore si elles pourront un jour donner lieu à une réalisation quelconque.

   Même si j'étais très ignorant de ce qu'était le chercheur, dont l'image pour moi était celle du savant du XIX^e siècle, je pensais, et je persiste à penser, que les métiers de chercheur et d'ingénieur sont complémentaires, sauf sans doute dans des domaines très abstraits et très théoriques où l'ingénierie n'a guère de place. En lisant les brochures d'orientation scolaire, pendant mon année de Maths-Élem, je découvris avec enthousiasme le diplôme de Docteur-ingénieur, qui me semblait réunir les qualités des deux métiers. Quelques décennies plus tard, il me fallut apprendre que ce diplôme était considéré avec dédain par la nouvelle aristocratie française, celle des grands corps de l'État et des intellectuels patentés issus des trois ou quatre écoles qui comptent. Pour cette élite, il ne faut surtout pas être qualifié d'ingénieur. Pour l'homme de la rue, c'est plutôt le chercheur qui est dédaigné, avec les plaisanteries détestables sur ceux qui cherchent et ceux qui trouvent. Bref, tout cela ne va pas, c'est un héritage cumulé de la société d'ancien régime et des aspects les moins recommandables de la révolution, dont la conséquence est le cloisonnement de la société française en castes étanches, autosatisfaites et acrimonieuses.

Qu'est-ce que la recherche ?

   La nature du travail de recherche est difficile à comprendre pour qui n'en est pas, et après ces trente années passées à son contact quotidien, il conserve pour moi des aspects mystérieux. Mais ce dont je peux témoigner, c'est que, pour qui s'y adonne sérieusement (comme ailleurs il y a des fumistes, des imposteurs et des gagne-petit), la recherche est un métier très dur, psychologiquement éprouvant (voir [3]), mal rémunéré et souvent peu gratifiant. Pour un qui reçoit le prix Nobel ou la médaille Fields, combien de travaux remarquables qui ne seront jamais reconnus ? Un exemple emblématique est celui de Rosalind Elsie Franklin, qui a contribué autant que Watson et Crick à la découverte de la structure de l'ADN et de son rôle, mais qui est morte avant le Nobel : qui se souvient de son nom ? Comme le souligne le texte mentionné ci-dessus note [3], ce n'est pas un métier pour quelqu'un qui a besoin d'assurance dans ce qu'il entreprend et de se sentir compétent dans son domaine, puisque par définition tout ce que l'on édifie peut s'écrouler en une heure. C'est un métier où votre position dépend de l'opinion de vos pairs : ce n'est pas forcément la plus indulgente.

L'ingénieur informaticien face à ses limites

   Le fonctionnement des entreprises (au sens large) où travaillent les ingénieurs fait qu'ils sont placés dans un environnement technologique donné, où ils ont des problèmes techniques et organisationnels à résoudre. Ils sont ainsi exposés au risque d'une vision étroite, restreinte à cet environnement particulier. Ce qui leur permet éventuellement d'échapper à cette étroitesse de vue, c'est la culture (scientifique, mais pas seulement) qu'ils auront acquise au cours de leurs études et ensuite.

   Par rapport à ce problème, l'informatique présente un cas particulier, parce que l'existence d'une science informatique n'est reconnue que depuis peu, et encore du bout des lèvres (voire pas du tout) par les élites susmentionnées. C'est une différence avec des domaines comme la thermodynamique ou l'électricité, où travaillent des ingénieurs, mais dont tout le monde sait que derrière il y a de la science, sans laquelle les ingénieurs ne pourraient pas grand-chose.

   Dans ce contexte, beaucoup d'ingénieurs informaticiens ont tendance à sous-estimer la dimension scientifique de leur propre travail. Tel était d'ailleurs mon cas personnel pendant les quinze premières années de ma vie professionnelle, jusqu'à ce que j'assiste à un séminaire lumineux de Philippe Breton et Pierre Lévy, organisé par le Creis [4], où nous reçûmes copie des textes fondateurs (et en ces années 1980 fort peu accessibles) d'Alan Turing, John von Neumann, Warren McCulloch, Walter Pitts et Norbert Wiener. Plus tard j'entrai au Cnam, et en contact avec des chercheurs en informatique, ce qui me permit d'apprendre que le monde des réseaux relevait, lui aussi, d'une science (merci à Éric Gressier et à Claude Kaiser).

   Une des manifestations de l'étroitesse de vue qui menace l'ingénieur informaticien, c'est l'allégeance à la technologie d'un industriel particulier. En effet, un ordinateur, un système d'exploitation, un protocole de réseau sont des objets d'une extraordinaire complexité, sans commune mesure avec celle d'un moteur à explosion, ou même avec celle d'un avion (si l'on fait abstraction des centaines de calculateurs qui lui permettent de voler). L'ingénieur qui travaille avec un type particulier d'ordinateur et de système d'exploitation doit consacrer des années à en apprendre les caractéristiques et le fonctionnement. À l'issue de cet apprentissage (parler d'issue est d'ailleurs abusif, ce n'est jamais terminé), il est sans doute émerveillé par ce qu'il a découvert ; ce capital de connaissances constitue dès lors sa valeur, non seulement sur le marché du travail, mais aussi aux yeux de ses pairs. Changer d'univers technologique, c'est repartir à zéro, redevenir un débutant.

De beaux jardins aux barrières infranchissables

   À mes débuts, mon univers de référence était celui des systèmes IBM, dont j'étais un expert. Lorsque je quittai l'Insee pour l'Ined, tout dans mon nouveau poste était bien mieux que dans le précédent, mais il y avait une ombre au tableau : l'Ined n'était pas équipé d'IBM, mais de Digital Equipment (DEC). J'avais l'impression de déchoir. En fait, au bout de quelques mois, à ma grande surprise, je découvris que la technologie de DEC était par bien des aspects supérieure à celle d'IBM. C'est ainsi qu'un doute salubre s'instaura dans mon esprit. Rappelons qu'au début des années 1970 IBM détenait plus de 90 % du marché informatique mondial, qui était presque exclusivement celui du matériel informatique, puisque le logiciel et les services étaient fournis comme des prestations annexes à la location des ordinateurs, très chers. Comme on le voit, les bouleversements de ce secteur ont été considérables en quarante ans, on l'oublie parfois.

   Aujourd'hui, l'entreprise qui me semble adopter des pratiques de monopole analogues à celles d'IBM jadis (qui soit dit en passant a su très bien s'adapter aux évolutions du marché), c'est Cisco dans le domaine des équipements de réseau. Comme IBM en son temps, une des grandes forces de Cisco réside dans les cerveaux des milliers d'ingénieurs qui maîtrisent parfaitement sa technologie, qui ignorent celles des concurrents, et qui ressentent donc comme une menace l'éventualité d'un changement de fournisseur. Cisco leur délivre d'ailleurs des certificats de compétence, qui prétendent rivaliser avec les diplômes universitaires, ce que faisait également IBM en son temps. Les formations Cisco, comme celles d'IBM, sont étroitement adaptées à la maîtrise des matériels et des logiciels du fournisseur, mais sont à l'opposé d'une formation universitaire qui doit fournir aux étudiants une vision d'ensemble, seule à même de leur procurer le recul nécessaire à une carrière de toute une vie. Et, comme celle d'IBM, la technologie de Cisco est intentionnellement rendue compliquée et opaque, ce qui renforce l'emprisonnement des ingénieurs dans un jardin enclos de barrières difficiles à franchir.

   On le voit, la menace qui pèse sur les ingénieurs informaticiens, c'est le conservatisme, encouragé par les fournisseurs. On comprend qu'ils n'aient pas envie de voir remises en cause des compétences qui ont mis des années à être acquises, mais dans un secteur en évolution rapide, le conservatisme est suicidaire à terme, même si la croissance rapide du secteur peut en masquer les dangers.

Mêler chercheurs et ingénieurs : au Cnam

   Si je passe en revue les épisodes de ma vie professionnelle, soit une douzaine d'années comme « militant de base » et une trentaine à la tête d'équipes de tailles variées (de trois à trente ingénieurs, chercheurs ou techniciens), les situations les plus productives que j'ai connues furent celles où chercheurs et ingénieurs étaient étroitement associés, sur un pied d'égalité. Et à chaque fois, au bout de quelques années, cela a fini par éclater, parce que le système français est allergique à de telles organisations, qui transgressent les barrières entre catégories sociales.

   Pour prendre une situation que je n'ai pas vécue personnellement, mais dont j'ai assidûment fréquenté les protagonistes, je citerai la création de ce que l'on peut appeler le « réseau UUCP » des machines Unix pour accéder, en France, à la messagerie Unix et aux news Usenet, dit « réseau Fnet ». Ce travail a été analysé et décrit par Camille Paloque-Berges, chercheuse au Cnam, dans un article à paraître [5]. Claude Kaiser m'a également fourni des informations détaillées.

   Comme nous l'apprend Camille Paloque-Berges (le texte d'une chercheuse qui a consulté les archives du Cnam est plus fiable que ma mémoire), la France fut en 1983 un des premiers pays à accéder, par le protocole UUCP (Unix to Unix Copy), au réseau de messagerie Unix et de forums Usenet. Ce fut le travail d'une petite équipe d'ingénieurs de recherche [6] du Laboratoire d'informatique du Cnam autour d'Humberto Lucas et de Bernard Martin. De 1974 à 1982 Claude Kaiser [7], lui-même ingénieur de formation devenu enseignant-chercheur, travailla avec le laboratoire, alors dirigé par Humberto Lucas. Le réseau fut baptisé Fnet.

   Le Laboratoire d'informatique du Cnam (dont je fus directeur de 1988 à 1991) assurait en 1982 les fonctions de centre de calcul pour le Cnam, de noeud d'accès au réseau avec une liaison vers Amsterdam, centre européen d'accès au réseau Unix, ainsi que des activités de recherche, principalement autour d'Unix. Par exemple, c'est grâce au réseau mis ainsi en place que Véronique Donzeau-Gouge, membre de l'équipe de conception du langage Ada dirigée par Jean Ichbiah, a pu participer à ce travail d'une équipe internationale reliée essentiellement par communications électroniques [8]. Le statut de ce laboratoire était ambigu, à cheval entre la recherche et l'ingénierie, et c'était justement ce qui lui permettait d'avoir de vraies réalisations de pointe à son actif. La direction du Cnam n'y a rien compris, elle n'a pas vu qu'elle tenait le moyen d'être à l'origine de l'Internet en France, Humberto Lucas et Bernard Martin, très maltraités par le mandarinat local, partirent vers de meilleurs cieux. Après leur départ, le backbone du réseau Fnet émigra à l'INRIA où il fonctionna sous la direction d'Yves Devillers. Il y eut aussi un passage par l'IRCAM, avec Michel Fingerhut, dont la chronologie ne m'est pas exactement connue.

Informatique scientifique à l'Institut Pasteur

   En 1991, après trois ans à la tête du Laboratoire d'informatique du Cnam, je supportais moi-même de moins en moins bien l'attitude suffisante du corps professoral local, suffisance qui ne me semblait pas toujours la contrepartie de qualités intellectuelles exceptionnelles. Une amie pasteurienne, Dominique Morello, m'avait mis en contact avec François Rougeon, Directeur de la recherche à l'Institut Pasteur, qui avait pris conscience du retard que prenait l'Institut dans le domaine de l'informatique scientifique, et nous commençâmes à réfléchir ensemble aux moyens de combler ce retard. À la fin de l'année, je rendis mon tablier au Cnam et rejoignis l'Institut Pasteur pour y créer un Service d'informatique scientifique [9].

   L'aventure dura dix ans. Tout était à faire. La situation était assez lamentable, avec les survivants d'une ancienne équipe d'informatique scientifique, au sein de laquelle le rang hiérarchique implicite était inversement proportionnel au contact réel avec l'informatique, puisque pour appartenir au clergé il fallait pouvoir se dire, peu ou prou, « scientifique », c'est-à-dire biologiste. Les informaticiens étaient définitivement considérés comme du Tiers-État.

   Mon premier travail fut de recruter quelques ingénieurs au fait de l'informatique contemporaine, ce qui nous permit de créer une infrastructure de calcul conforme à l'état de l'art, un réseau de campus (il n'y en avait pas), et de raccorder le tout à l'Internet. J'ai toujours la copie du message électronique de Kim Hubbard, du nic.ddn.mil, pour l'attribution d'un réseau de classe B (2¹⁶ adresses IP), le 19 décembre 1991, via Bitnet. À l'époque il fallait pour cela justifier d'une activité académique, mais les huit prix Nobel reçus à l'époque par l'Institut Pasteur firent bonne impression.

   Une fois l'infrastructure construite, nous installâmes les logiciels nécessaires à l'activité scientifique de l'Institut, puis nous organisâmes des formations pour les chercheurs. Tout ceci est écrit en détail dans le rapport d'activité de 1998, établi pour l'évaluation de l'équipe.

   Les cours dispensés étaient de deux types : des formations à l'usage des logiciels d'analyse de séquences biologiques, de modélisation moléculaire et de phylogénie, certes. Mais cela ne suffisait pas, il fallait aussi donner à des chercheurs une vraie formation à l'informatique, pour les raisons détaillées ici [10]. En effet, l'usage des systèmes complexes que sont les logiciels scientifiques sans en comprendre le fonctionnement ne convient pas à un vrai travail de recherche. À cette fin, à l'initiative de William Saurin, nous créâmes un cours d'informatique fondamentale orientée vers les préoccupations des biologistes, de format Master 2 (350, puis 400 heures, à plein temps pendant un trimestre). Ce cours connut un public international et exista jusqu'en 2008.

   En même temps se développa au sein de l'équipe une véritable activité de recherche au sens académique du terme, notamment après la venue de Marie-France Sagot, qui venait de soutenir une thèse remarquable [11], puis avec les travaux de Catherine Letondal.

   Dire que le Service d'informatique scientifique fut pendant cette décennie un des principaux facteurs d'évolution de l'Institut Pasteur n'est pas exagéré. Le passage à l'informatique, qui se heurtait à de fortes réticences des chercheurs « installés » dont cela menaçait les positions, était une question de survie scientifique pour l'institution, menacée de ridicule pour son retard en 1991, et dont six ans plus tard le site Web avec son offre de logiciels scientifiques et de bases de données en libre accès était une référence au niveau mondial.

   Comme dans le cas du Cnam, cela ne fut pas perçu par l'institution, l'équipe fut démantelée en 2001.

Conclusion

   De ces expériences, je retire que, si les ingénieurs laissés à eux-mêmes sont menacés par la tentation du conservatisme technique et de la routine, dans un domaine tel que l'informatique, où les réalisations concrètes comptent, des chercheurs laissés à eux-mêmes risquent de tourner en rond faute de moyens suffisants pour mettre leurs idées à l'oeuvre [12]. La réunion de chercheurs et d'ingénieurs est beaucoup plus productive, les ingénieurs sont stimulés par les idées des chercheurs, qui trouvent dans le même couloir le soutien nécessaire aux réalisations techniques qui prolongent leurs travaux. Pour que cela marche, il faut bien sûr que cela ne se passe pas, comme il est de règle dans les institutions de recherche françaises, selon un rapport de sujétion des frères converts aux membres du clergé.

   Une grande partie des activités des équipes mixtes évoquées ci-dessus étaient de la recherche : pas au sens académique du terme, certes, plutôt de la R&D, avec à la clé pas des articles, mais des choses novatrices qui fonctionnent, ce qui ne me semble pas déshonorant. Je dois constater que les auteurs de ces travaux (dont l'auteur de ces lignes) n'ont pas été très bien traités par le mandarinat universitaire.

   En 1986, avec un groupe de collègues, j'ai eu l'occasion de visiter la Computer Science Division du campus de Berkeley de l'Université de Californie, pas vraiment une institution de seconde zone, où nous avons été reçus par le Chairman de l'époque, le professeur Domenico Ferrari (un italien d'Italie, pas un italo-américain, viticulteur pendant les vacances universitaires). J'ai conservé la brochure de présentation de la division : on y trouve beaucoup de noms devenus célèbrissimes depuis, et bien sûr beaucoup de thèmes de recherche théorique, mais aussi, y compris associés à de grands noms, des sujets qui en France, du moins à l'époque, eussent été jugés à peine dignes d'un IUT, parce que trop informatiques et pas assez du côté du monoïde libre. On me permettra de préférer la vision de Berkeley, et je suis sûr de ne pas me tromper (c'est facile).

Laurent Bloch
Chercheur en cyberstratégie à l'Institut français d'analyse stratégique

Paru le 16 octobre 2013, sous licence Creative Commons BY, sur le site de Laurent Bloch :
http://www.laurentbloch.org/MySpip3/spip.php?article275

NOTES

[1] « Qui seront les ingénieurs de demain ? »
http://blogs.lesechos.fr/paristech-review/qui-seront-les-ingenieurs-de-demain-a13937.html#xtor=CS3-5

[2] L'Institut national d'études démographiques (Ined).
http://www.ined.fr/

[3] « Reflections on being a researcher »
https://dewdrinker.wordpress.com/2012/08/16/dewdrinker/

[4] Creis-Terminal, Informatique et société.
http://www.lecreis.org/

[5] Between electronic frontier and electronic agora : the role of Unix computer networks in France and Europe in the promotion of Internet's technologies and values as a technical democracy.
By Camille Paloque-Berges
Post-Researcher at Laboratoire d'Excellence HASTEC, Pres HESAM
Associate researcher at laboratoire DICEN, CNAM, Paris (France).
Working paper (v1 : 27/08/2013) for the 6th Plenary Conference of "Tensions of Europe", ANR Resendem : "Democracy and Technology. Europe in Tension from the 19th to the 21th Century", 19-21 September 2013, Sorbonne Paris (France).

[6] La locution ingénieur de recherche désigne un corps de fonctionnaires des établissements d'enseignement supérieur et de recherche français. J'ai appartenu à ce corps jusqu'à ma retraite. Dans le système français de castes, il constitue un paradoxe, parce que contrairement aux chercheurs, les ingénieurs de recherche ne sont soumis ni à l'évaluation par les pairs, ni à l'impératif publish or perish. Ils bénéficient d'un certain confort dont la contrepartie est une moindre considération. Dans les meilleurs des cas, comme celui dont il est question ici, cela permet d'entreprendre un travail de longue haleine sans être soumis à la pression des commissions de classement.

[7] « Curriculum vitae détaillé de Claude Kaiser ».
http://cedric.cnam.fr/~claude/CKCVDetails2009.pdf

[8] Véronique Donzeau-Gouge Viguié, communication personnelle, 1988.

[9] Cf. son Rapport d'activité de 1998 :
http://www.pasteur.fr/recherche/unites/sis/Rapport/html-activ.html.

[10] Laurent Bloch, « Enseigner l'informatique aux biologistes »
http://www.laurentbloch.org/MySpip3/spip.php?article244

[11] Bibliographie de Marie-France Sagot.
http://pbil.univ-lyon1.fr/members/sagot/htdocs/publications.html

[12] Il y a aussi des chercheurs capables d'être, si je puis dire, leurs propres ingénieurs, de développer eux-mêmes leurs idées en logiciels opérationnels, comme Christian Queinnec, Manuel Serrano, Xavier Leroy. De telles capacités ont été la marque du monde Unix, spécialement BSD. Ce n'est pas le cas le plus fréquent.