Sciences et Technologies de l'Information
Sommaire : Cinq questions à Gérard Leblanc | L'actualité de la semaine | Théories et concepts | Entreprises| Manifestations | Le livre de la semaine | Détente.
Asti-Hebdo
: Vous êtes enseignant et vous avez publié de nombreux
livres sur la programmation, dont j'ai pu apprécier pour
moi-même l'efficacité pratique et prédagogique.
Quel vous paraît, actuellement, le point le plus important ou
le plus difficile à faire comprendre à ceux qui
apprennent la programmation ?
Gérard Leblanc : Je ne pense pas qu'il y ait, sur le plan technique, des domaines plus difficiles à faire comprendre. Il faut, pour y parvenir, deux conditions. D'une part que l'enseignant possède son sujet et croie en ce sujet, qu'il ait envie de le défendre. D'autre part que les enseignés aient les prérequis. Tout est alors question de motivation et de manière de présenter le sujet. Je crois aussi qu'il est toujours possible de présenter n'importe quel sujet avec des mots de tous les jours. Cela n'exclut pas le recours à des démonstrations rigoureuses ou à des techniques élaborées mais les deux (l'intuition et la rigueur) me paraissent indispensables. Bien qu'étant un rationaliste aussi convaincu qu'intransigeant, j'aime donner un coup de pouce au raisonnement intuitif (toujours soutenu par la rigueur) car c'est surtout celui que l'on retient.
Prenons un exemple, assez personnel. Quand j'ai découvert la récursivité, on m'a présenté deux exemples : la factorielle et le problème dit des tours de Hanoï. Je n'avais et je n'ai d'ailleurs toujours rien, mais rien, à faire du problème des tours de Hanoï. Je ne pouvais même pas utiliser l'algorithme dans la vie de tous les jours pour impressionner quelqu'un avec ce casse-tête (en supposant que quelqu'un soit prêt à m'admirer pour cela). Quand, sur les machines de l'époque, j'ai eu mes premiers "stack overflow" et ai pu évaluer l'impact sur les performances, j'ai pris la récursivité en grippe, au point de douter de l'état de santé mentale de ceux qui s'extasiaient devant cette technique.
Et pourtant, si l'on propose à un étudiant de balayer un répertoire avec ses fichiers et ses sous-répertoires, si l'on attend qu'il se casse les dents avec les techniques traditionnelles et qu'on lui présente la récursivité, celle-ci apparaît alors comme lumineuse et efficace. On pourrait multiplier les exemples.
Les générations d'étudiants prêts à ingurgiter l'annuaire téléphonique, tout simplement parce que l'on exige cela d'eux, appartiennent au passé. Et je m'en réjouis. A nous d'être concrets et de commencer par montrer à quoi cela sert. Je suis toujours sidéré par les mathématiciens (pas tous heureusement mais beaucoup quand même) qui n'ont parfois qu'une idée fort approximative de l'usage qui est fait de certaines théories mathématiques. Certains semblent même désolés d'apprendre qu'il y ait des applications pratiques.
Asti-Hebdo : Les nouveaux systèmes d'exploitation (typiquement Windows) ont fait apparaître de nouveaux environnements de programmation (Visual, Delphi...), à forte base graphique. Quels problèmes cela pose-t-il à l'enseignant ?
G.L. : Pour l'apprentissage de la programmation (j'insiste, je parle de la phase initiale d'apprentissage), les environnements graphiques ont apporté plus d'inconvénients que d'avantages. Parce que, avant même de démarrer, un programme à interface graphique évoluée (généralement Windows) a besoin de toute une infrastructure de plus en plus cachée au développeur mais pourtant bien présente. Dans mes livres de programmation Windows, je tiens à expliquer cette face cachée, au moins dans ses grandes lignes. Mais pour les jeunes, à ce moment, je parle de la guerre de 14...
Ma faveur va encore à des environnements conviviaux comme Turbo C ou Turbo Pascal qui créent des programmes pour le mode console. Cela paraît pour le moins désuet à certains, qui ont le sentiment d'apprendre des technologies dépassées. Je ne sais pas combien de temps on va pouvoir encore résister mais cela vaut la peine d'expliquer que l'on est au stade de l'apprentissage des bases et que l'étude des algorithmes est bien plus importante que la belle interface professionnelle, voire tape-à-l'oeil. Chaque chose en son temps. Il en va de même pour tous les apprentissages. Les étudiants en médecine s'exercent au maniement du bistouri sur des corps inertes, l'auscultation d'Adriana, Claudia ou Laetitia ne venant que bien plus tard, quand elle a lieu. C'est peut-être bien dommage mais il est préférable qu'il en aille ainsi.
Que des étudiants, tout au début de leur cycle, me paraissent aussi pressés m'inquiète quelque peu. Qu'on cesse aussi de leur rabâcher qu'ils sont là pour créer leur propre entreprise dans les semaines à venir et que le succès de Bill Gates est à leur portée et pour tout de suite.
Ceci dit, je suis farouchement opposé aux compilateurs et outils de développement en mode ligne de commande. Je dis non encore à l'adage "Tu programmeras dans la douleur" même si certains trouvent à la souffrance des vertus pédagogiques. Je rejoins ici votre souci de l'utilisateur : on ne peut pas demander à quelqu'un de faire son apprentissage avec de tels outils antédiluviens et en même temps de le presser à créer des programmes qui prennent en compte le confort de l'utilisateur. Ou alors ces outils agissent comme contre-exemples.
Après la phase initiale d'apprentissage, j'avoue exploiter l'impatience des étudiants à réaliser des programmes professionnels. Mais il faut canaliser cette impatience. Travailler comme un professionnel et adopter le plus rapidement possible des réflexes de "pro", cela s'apprend. Je fais utiliser la version .NET de Visual Studio de Microsoft, avec maintenant le C# comme langage.
Pour l'enseignement de l'informatique, le grand tournant n'a cependant pas été l'apparition de ces outils. Cela ne me rajeunit pas mais le grand tournant a été la disparition des cartes perforées ! La raison en est simple : comme le cycle encodage, compilation, exécution et obtention des résultats prenait souvent au moins un jour, il fallait écrire ses programmes sur papier et les vérifier mentalement avec le plus grand soin. Aujourd'hui encore, certains regrettent cette époque. Je peux les comprendre : il suffisait de prononcer goto pour être immédiatement engagé comme un génie de l'informatique. Un bon informaticien se reconnaissait aussi au premier coup d'oeil : il portait des tas d'élastiques aux poignets (il fallait bien ficeler les paquets, les decks de cartes comme on disait). Et puis, aux mariages ou en boîte, c'était celui qui arborait une carte perforée à la boutonnière...
Regretter ce temps ou interdire le passage sur machine ne sert à rien. Les ordinateurs personnels sont là et ils seront quand même utilisés. Il faut certes d'abord réfléchir sur papier mais le passage sur machine constitue aussi une école de rigueur, indispensable pour moi. J'enrage quand j'entends dire yaka ou yapluka programmer. Il y aurait moins d'erreurs dans les pseudo-codes d'algorithmes de rebalancements d'arbres binaires si l'auteur avait pris la peine de programmer et de tester son algorithme sur machine.
Quant aux langages, ma préférence va au C# introduit récemment par Microsoft avec l'architecture .NET. Ce langage s'inscrit dans la lignée C, C++ et maintenant C#. Il est vraiment bien adapté au développement par objets et composants. Pour moi, il combine les avantages du C, du C++ et de Java et en présente bien d'autres encore. J'ai tout de suite été enthousiaste. J'ai tout de suite perçu qu'un langage conçu par celui qui avait créé Turbo Pascal puis Delphi chez Borland ne pouvait qu'être exceptionnel. Anders Heljsberg avait aussi conçu, dès son arrivée chez Microsoft, les classes Java de programmation Windows. Je n'ai pas été déçu.
Mais le choix du langage n'est plus l'élément essentiel. L'architecture .NET de Microsoft en fournit d'ailleurs un exemple saisissant. Tous les langages de l'architecture .NET doivent être orientés objets (un point souvent d'achoppement pour ceux qui ont appris VB sur le tas et ne se débrouillaient d'ailleurs pas mal avec VB6 mais VB.NET va bien au-delà). Tous ces langages utilisent les mêmes classes, les mêmes interfaces et les mêmes outils de développement. On choisit alors son langage le plus approprié à la tâche ou en fonction de critères personnels. Ce n'est pas négligeable, chacun peut y trouver son compte mais c'est vrai que le choix de l'architecture est devenu bien plus primordial que celui du langage.
Asti-Hebdo : Dans ceux de vos livres que j'ai lus, vous parlez assez peu des utilisateurs. Est-ce un choix délibéré ?
G.L. C'est vrai, mes ouvrages peuvent donner l'impression que je parle peu des utilisateurs. Je dirais plutôt : j'en parle peu explicitement. Un peu comme ces personnes qui, par timidité, pudeur ou discrétion, ne parlent que rarement d'elles-mêmes. Alors que leur personne est vraiment au coeur de leurs préoccupations... Souvent même plus que ceux qui parlent à tout bout de champ d'eux-mêmes.
Il faut d'abord s'entendre sur le terme d'utilisateur. Mes utilisateurs à moi, ce sont mes lecteurs ou ceux qui suivent mes formations. Tous sont des développeurs ou en passe de l'être (mais déjà avec une mentalité de développeur). Il s'agit même le plus souvent de développeurs d'une informatique très technique. Il y a donc une couche entre ce que l'on appelle communément l'utilisateur final et moi-même. Une couche au sens informatique du terme, pas un écran. Je peux vous assurer que mes "utilisateurs" à moi sont véritablement au centre de mes préoccupations. C'est en pensant à eux, en me posant les questions qu'ils doivent se poser, en répondant à leurs questions, en pensant aux problèmes qu'ils doivent rencontrer que j'écris mes ouvrages. J'espère que ces développeurs feront, à leur tour, preuve de la même attitude face à leurs utilisateurs à eux. En fait, je n'espère pas, j'en suis convaincu car je crois beaucoup aux vertus de l'exemple.
Indirectement comme je viens de vous l'expliquer mais aussi directement même si c'est moins perceptible, l'utilisateur final est au centre de mes préoccupations. Face à un nouveau logiciel ou un nouvel appareil, j'aime jouer à l'utilisateur même "lambda". Pas pour faire l'idiot mais pour mieux comprendre les problèmes que peuvent rencontrer ces gens qui veulent tout simplement que cela marche, sans devoir investir un temps considérable dans l'informatique. Les développeurs doivent être capables de se mettre dans la peau de ces gens, cela me paraît indispensable.
Puisque vous avez lu certains de mes ouvrages, vous m'accorderez que j'aime expliquer, exemples à l'appui, comment rendre les programmes plus conviviaux ou comment résoudre des problèmes que vont, un jour ou l'autre, rencontrer les praticiens. J'ai le plus grand respect, parfois même de la mansuétude, pour ceux qui vont au charbon. Mais ces développeurs, à leur tour, ont obligation de respect vis-à-vis de leurs utilisateurs. Je suis toujours hors de moi quand j'entends un informaticien parler de chimpanzee (prononcé à l'américaine, c'est plus méprisant) pour désigner l'utilisateur lambda. Je supporte pas cette forme de condescendance.
Asti-Hebdo : Comment faites vous pour vous informer de ce qui est bon pour les utilisateurs et le faire passer cela auprès de vos élèves ?
G.L. Je considère qu'un logiciel destiné à d'autres qu'à son auteur n'est pas achevé s'il n'est pas convivial. Sauf exceptions d'ailleurs de plus en plus rares, je ne supporte plus les programmes en mode ligne de commande.
Je crois d'ailleurs que le drame d'Unix est là. Dommage qu'il y a quinze ou vingt ans, un responsable de produit n'ait pas réuni les développeurs d'Unix et leur ait dit : "Messieurs, Unix ne se vend pas par manque de convivialité. A moins d'apporter des solutions radicales et novatrices dans ce domaine, nous courons à la catastrophe et nous serons bientôt tous licenciés". Mais voilà, Unix était gratuit et ses utilisateurs s'accommodaient de ce manque de convivialité. Aujourd'hui encore certains semblent même tirer fierté de cette situation et revendiquent cette appellation de "power user", tellement condescendante pour les "end users".
Réaliser des logiciels en faisant preuve de respect pour l'utilisateur s'apprend (j'adore cela, c'est le domaine particulièrement vaste de la programmation Windows, l'objet de plusieurs de mes livres) mais il faut encore autre chose.
Pour expliquer cette chose, j'aime faire référence à une discussion avec un professeur de peinture à l'Académie des Beaux-Arts. Avec une certaine mauvaise foi, je l'interrogeais sur l'utilité de ces formations : on a le don de la peinture ou on ne l'a pas. Il m'a répondu qu'il apprenait essentiellement une chose : "à regarder, puis à voir et finalement à rendre d'une manière ou d'une autre cette réalité".
Cela s'applique aux informaticiens :
Asti-Hebdo : Dans sa vie professionnelle, un programmeur travaille rarement seul. Comment inculquer le sens de l'équipe au moment de la formation ?
G.L. La société a le don de réclamer des enseignants la promotion de certaines valeurs (j'y souscris entièrement) et en même temps de populariser des modèles qui sont aux antipodes ou tout au moins très éloignés de ces valeurs. Des métiers comme instituteur ou infirmière sont déconsidérés alors que l'on glorifie des joueurs de football, des top-models, des star-académiciens ou de simples lofteurs.
Il en va de même en informatique. Prenons l'exemple de Ken Thompson et de Dennis Ritchie, les concepteurs d'Unix et du C. Ils étaient chercheurs chez Bell dans le New Jersey. Ils avaient en charge la réalisation d'un logiciel de simulation de déplacements d'étoiles. A les croire, il n'existait pas à l'époque de système d'exploitation et de langage leur convenant pour ce travail. A l'époque pourtant, les constructeurs étaient bien plus nombreux et différenciés qu'aujourd'hui. Ils avaient tous leurs propres systèmes d'exploitation, tous différents. Il y avait aussi une profusion de langages que l'on ne connaît plus aujourd'hui.
Disons les choses comme elles sont, avec l'énorme respect et l'admiration que je porte à Thompson et Ritchie : on avait affaire à deux fortes personnalités atteintes du syndrome NIH (Not Invented Here). Tant mieux pour le développement de l'informatique (ce n'est pas moi qui vais minimiser l'apport du C) mais avouez que les modèles de réussite (et je me limite ici à la reconnaissance technique) vont souvent à l'encontre de ce que l'on aimerait promouvoir, à savoir le travail en équipe et l'utilisation optimale de l'existant.
La technique s'y est mise, aussi : pensez à l'apport de la programmation orientée objets. Tout concourt à réaliser des composants opaques qui ne communiquent avec d'autres composants qu'au travers d'interfaces bien définies. On ne peut que s'en réjouir mais cela change la signification du travail en équipe. Chacun peut travailler dans sa bulle, à partir du moment où ces interfaces sont respectées.
N'oublions pas non plus la tradition académique : on demande aux enseignants (plus individualiste que cela, tu meurs) d'apprendre à travailler en équipe mais on leur demande aussi de sélectionner, d'éliminer, de calibrer et de classer les étudiants. Et cela, évidemment, sur des bases de performances hautement individuelles. Pas question lors d'un examen de faire appel à l'équipe ou d'aider un condisciple ! Là où le classement joue un rôle, la faculté d'asséner avec sérénité des coups bas est plus rentable que l'esprit d'équipe.
Ne me faites pas non plus dire ce que je ne dis pas : il faut évidemment favoriser le développement de projets réalisés en équipe. Mais cela ne s'apprend pas comme on apprend une matière technique. Cela se vit, notamment lors des stages en entreprises.
Pour inculquer le sens de l'équipe, il faut avant tout donner des connaissances très larges, à la fois théoriques et pratiques. Car pour pouvoir travailler en équipe, il faut être conscient de plusieurs choses. La première est qu'on ne peut pas être particulièrement compétent en tout, que d'autres sont peut-être mieux à leur place et qu'ils vont donc apporter plus que l'on peut donner. La deuxième que l'on est peut-être plus compétent que d'autres dans certains domaines et donc que l'on constitue peut-être une richesse pour les autres. La troisième est que, grâce à une formation solide, on peut comprendre et donc mieux apprécier le travail des autres.
Il reste les incorrigibles individualistes qui parfois font merveille en informatique. Ma femme vous dirait, mais ne le répétez pas, qu'au royaume des individualistes pathologiques, j'aurais acquis du galon...
Claudie Haigneré, ministre chargée de la Recherche et des nouvelles technologies, a exposé le 25 septembre 2002 le projet de budget civil de recherche et de développement technologique (BCRD) pour l'année 2003. Les axes principaux structurant ce budget sont notamment : l'objectif "essentiel" des "3% du PIB à la Recherche en 2010" ; "plus de 9 500M d'euros de ressources publiques disponibles pour soutenir l'effort de R&D en 2003" ; la garantie, par le BCRD 2003, d'une "politique de l'emploi scientifique public adaptée aux besoins d'une recherche de qualité" et de "possibilités plus nombreuses de recrutement aux jeunes docteurs" ; "attirer les jeunes vers la recherche en leur offrant des perspectives attrayantes dans des domaines prometteurs" (revalorisation des allocations de recherche, création de 400 contrats...) ; "une recherche publique forte et ouverte" (accroissement des moyens de la recherche universitaire, garantie des moyens pour les établissements...) ; des "synergies entre la recherche publique et privée pour soutenir l'innovation" et l'accompagnement des "grands programmes industriels et stratégiques spatiaux et aéronautiques". Lire le texte de la conférence de presse.
Le Monde du 20 septembre signale que le Décrypthon a comparé 550 000 protéines. 75 000 volontaires ont mis à disposition la puissance de leur PC, reliés à 21 serveurs IBM.
Avec une régularité d'horloge, Springer annonce chaque semaine des livraisons nouvelles de sa série "Lecture notes on computer science". Notons :
Automates cellulaires. S. Bandini, B. Chopard, M. Tomassini (Eds.): Cellular Automata 5th International Conference on Cellular Automata for Research and Industry, ACRI 2002, Geneva, Switzerland, October 9-11, 2002. Proceedings
Théorie algorithmique de l'apprentissage Michael M. Richter, Carl H. Smith, Rolf Wiehagen, and Thomas Zeugmann (Eds.): Algorithmic Learning Theory 9th International Conference, ALT'98 Otzenhausen, Germany, October 1998. Proceedings
Gestion du multimédia sur Internet K.C. Almeroth, M. Hasan (Eds.): Management of Multimedia on the Internet 5th IFIP/IEEE International Conference on Management of Multimedia Networks and Services, MMNS 2002, Santa Barbara, CA, USA, October 6-9, 2002. Proceedings
UML J.-M. Jézéquel, H. Hussmann, S. Cook (Eds.): UML 2002 - The Unified Modeling Language 5th International Conference, Dresden, Germany, September 30 - October 4, 2002. Proceedings
Gouvernement électronique R. Traunmüller, K. Lenk (Eds.): Electronic Government First International Conference, EGOV 2002, Aix-en-Provence, France, September 2-5, 2002. Proceedings
Méthodes agiles D. Wells, L. Williams (Eds.): Extreme Programming and Agile Methods - XP/Agile Universe 2002 Second XP Universe and First Agile Universe Conference, Chicago, IL, USA, August 4-7, 2002. Proceedings
Traitement des chaînes et recherche de l'information A.H.F. Laender, A.L. Oliveira (Eds.): String Processing and Information Retrieval 9th International Symposium, SPIRE 2002, Lisbon, Portugal, September 11-13, 2002. Proceedings
Systèmes d'information orientés objet J.-M. Bruel, Z. Bellahsène (Eds.): Advances in Object-Oriented Information Systems OOIS 2002 Workshops, Montpellier, France, September 2, 2002. Proceedings
À l'occasion de son assemblée générale, le Cigref rend publics deux rapports :
- Afia
- Afig
- Afihm
- ASF
- ACM Sigops
- Atala
- Atief
- Cigref
- Creis
- GRCE
- Gutenberg
- Inforsid
- Specif
Deux managers informatiques (Francis Meston (EDS) et Hervé Nora (Framatome) et un journaliste spécialisé (Philippe Rosé, CIO) ont coopéré pour faire le point, et conclure de manière optimiste, sur les perspectives de l'informatique aujourd'hui.
Intitulé "Mirages et miracles des technologies de l'information" (Editions Village mondial) se termine ainsi : "Du temps des excès (de langage, d'investissements, de technologies peu matures... il reste inévitablement des traces. Cela impose une nouvelle discipline intellectuelle. (NDLR : sans doute pas une nouvelle discipline au sens scientifique, bien sûr). Indispensable dans un contexte d'ébullition technologique, elle se traduit par une cohérence des systèmes d'information au service des stratégies d'entreprises et par une cohérence des discours face aux enjeux".
On appréciera en particulier les deux séries de dix dénonciations : "idées fausses mises à nu" et "mythes d'Internet". Les auteurs y balaient superbement quelques thèmes à la mode comme le paradoxe de Solow (l'informatique n'améliore pas la productivité) ou la grande communauté des internautes.
Assez loin des Stic dans cet ouvrage, au moins en apparence, le général Loup Francart, aidé d'Isabelle Dufour analyse les attentats du 11 septembre et leurs suites, du point de vue de l'information et de la décision. "Statégies et décisions" (Economica) fait donc assez logiquement suite à "Infosphère et intelligence stratégique" récemment publié par Loup Francart chez le même éditeur (voir Asti-Hebdo no 82).
"Traduction automattique et soupe informationnelle" ! Nous aurions dû mettre cette référence dans la rubrique "concepts"... Les auteurs et l'éditeur nous pardonneront de l'avoir reportée à la rubrique "détente"... On sait que la traduction automatique a toujours suscité l'humour, au moins depuis le fameux "Les spiritueux sont bons, mais la viande est avariée", supposé traduire le dicton évangélique "L'esprit est prompt mais la chair est faible" (Mt 26, 41).
On nous parle ici de soupe informationnelle... est-ce pour redonner du tonus à la chair ? On se rassurera en consultant le sommaire de l'ouvrage que David Farwell, Laurie Gerber et Eduard Hovy (eds.) viennent de publier chez Springer, Machine Translation and the Information Soup (Actes de la Third Conference of the Association for Machine Translation in the Americas, AMTA'98, Langhorne, PA, USA, October 1998.)
Armand
Berger nous communique (de source inconnue, nous serons heureux de
rendre hommage si l'auteur du cliché a encore les moyens de
s'offrir un abonnement à Internet) un photographie
récente de prestataire réduit à la
dernière extrémité.
La situation de l'emploi dans les métiers des Stic a toujours évolué en dents de scie. Tantôt suscitant l'inquiétude des employeurs en manque de demandeurs d'emplois qualifiés (Mais que font donc les universités au lieu de nous fournir de bonnes charretées de programmeurs), tantôt suscitant l'inquiétude des responsables de l'emploi s'interrogeant sur l'avenir des étudiants sortant des multiples filières de formation (Mais que font donc les universités, qui suivent la mode sans se préoccuper des besoins des entreprises)...
Ne perdons pas espoir. Saint Nasdaq remontera peut-être des Enfers et sauvera les nouvelles (et les pas trop anciennes) générations de sticiens !