Cet texte est issu d'un cours donné à des personnels de l'IGN le 25 novembre 2009. Michel Volle, qui était l'organisateur de la formation, a bien voulu prendre des notes à partir desquelles j'ai constitué les lignes qui suivent.
#Sommaire-
Introduction : le système d'information, en fin de compte, peut être utile
Une grande partie du contenu de ce cours est issue d'un livre que j'ai publié en 2005 chez Vuibert, Systèmes d'information, obstacles et succès, désormais épuisé chez l'éditeur, ce qui me permet de le proposer en accès libre et gratuit sur mon site sous un titre qui me plaît mieux, La pensée aux prises avec l'informatique.
Le début de ma carrière s'est déroulé à l'INSEE, puis à l'INED, au CNAM, à l'Institut Pasteur et à l'Inserm. Je suis maintenant DSI de l'université Paris-Dauphine, et cette nouvelle fonction m'a amené à tempérer quelques unes des idées du livre. Je crois vraiment maintenant qu'il y a des cas où un Système d'information (SI) peut être utile. A l'Inserm on aurait pu s'en passer : on dépensait beaucoup pour faire communiquer le système RH et le système comptable, ce n'était pas vraiment utile. Certaines parties de l'Inserm justifient un SI, mais pas l'ensemble ! C'est une coopérative d'artisans.
Dans une université, par contre, le SI est utile. On est en train d'implanter les espaces numériques de travail. Le SI s'adresse à des gens non professionnels dont le métier n'est pas le SI et il faut leur apporter les services de façon simple. Je suis désormais converti au SI. Il faut voir dans quelles conditions on va le mettre en place.
La révolution informatique
L'informatique représente actuellement dans le monde 30 % de la R&D; et 50 % de la croissance. La compétitivité des pays va tourner autour de l'informatique. Les entreprises et les pays qui ne parviendront pas à s'y adapter seront marginalisés, évincés. Ceci est à envisager dans la perspective des trois phases séculaires de la révolution industrielle : au tournant du XIXe siècle, la machine à vapeur, au tournant du XXe, l'électricité et le moteur à explosion, depuis 1975 l'informatique.
L'anthropologue Clarisse Herrenschmidt, dans son livre de 2007 Les trois écritures – Langue, nombre, code, mentionne trois autres révolutions, qui ont autant d'importance pour notre propos : l'invention de l'écriture du langage à la fin du IVe millénaire avant notre ère, celle de l'écriture numérique monétaire en Lydie à la fin du VIIe siècle avant notre ère, enfin celle de l'écriture informatique en réseau, dont nous sommes les contemporains.
Nul besoin d'insister sur l'ampleur des événements associés aux différentes étapes des révolutions industrielles et scripturales précédentes : révolutions politiques en Angleterre, aux États-Unis et en France, révolution religieuse dans toute l'Europe des XVIe et XVIIe siècles, pour ne citer que les exemples les plus évidents. Il serait surprenant que la révolution simultanée de l'industrie et de l'écriture issue de l'informatisation n'ait pas d'effets profonds et bouleversants.
Refus français de l'informatisation
Cependant la France résiste à l'informatisation. Les élites lui sont hostiles. Quand une personne me parle d'« outil informatique », je sais qu'il n'y aura rien de possible avec elle. Dire l'« outil Internet », c'est pareil. Ces gens-là croient qu'il ne s'agit que d'un outil, que cela ne change rien en profondeur : ils vont rester sur le bord de la route.
L'informatisation est donc un enjeu vital. Comment va-t-on la réussir, articuler l'informatique avec l'organisation ?
J'ai été client de l'IGN voici 25 ans. L'IGN opposait alors une forte résistance à l'informatisation. On voulait obtenir des fonds de carte, c'était difficile, l'IGN avait des fonds de carte informatisés depuis les années 1960, mais impossible de les obtenir dans des conditions techniques et financières acceptables. De même, le fonds de commerce de FT c'était le téléphone noir.
Aux États-Unis, tout ce qui a été payé par le contribuable est gratuit par la suite. L'INSEE aussi fait des recettes extra budgétaires, qui permettent d'échapper au carcan des marchés publics : mais cette chasse à la recette est un facteur de sous-développement. J'ai essayé de mettre en ligne la photothèque de l'Institut Pasteur. Mais ils voulaient les vendre ! On arrivait à vendre à des journalistes mal informés, qui n'avaient pas remarqué les photothèques gratuites et bien plus riches de certaines universités américaines.
Avec des collègues de Dauphine nous menons une réflexion sur les cours en ligne, mais les professeurs tiennent à leurs trois francs six sous de droits d'auteur tandis que la London School of Economics met tous ses cours en ligne, y compris ceux de professeurs comme Chomsky...
La conduite de projet : un bilan contrasté
Il faut réussir l'interface, la négociation entre l'informatique et l'informatisation. Le moyen standard proposé par tous les manuels est la méthode dite de « conduite de projet ». Je vais vous expliquer pourquoi cette méthode n'est en rien une panacée. Le mot projet vient de l'italien progetto, élément d'un bâtiment projeté en avant de la façade comme un bow window. L'inventeur du projet au sens moderne du terme est Brunelleschi, qui a construit la cathédrale de Florence. Il a inventé la méthode de conduite de projet.
Brunelleschi a dit qu'il fallait rédiger un cahier des charges écrit qui décrive les caractéristiques du projet à réaliser, puis faire réaliser ce document par les divers éléments de la maîtrise d'oeuvre. C'est là qu'on voit apparaître une distinction bien formalisée MOA-MOE. On peut consulter à Florence, au Museo dell'Opera del Duomo, le cahier des charges de Brunelleschi, aisni que ses maquettes, des sculptures et d'autres objets : on dit que c'est grâce à cette démarche qu'il a pu réaliser cette coupole, qui exigeait une coordination précise entre les charpentiers et les maçons.
La conduite de projet est un mode original de gouvernement qui vise à déterminer les meilleures conditions d'implantation d'une innovation dans une organisation. Au lieu de passer par la hiérarchie habituelle, on crée une équipe de projet qui sera responsable de la réalisation de façon transversale : ainsi on dépasse les limites de la pyramide hiérarchique, c'est important dans un pays comme France. C'est l'aspect à retenir de la méthode.
Cela semble donc être une bonne idée ! Mais d'après ce que j'observe en informatique, si le principe de l'organisation en équipe est profitable, le découpage du projet en phases selon les étapes classiques est un moyen très imparfait, qui conduit à un taux d'échec élevé, parce que l'informatique n'est pas une branche de l'industrie, elle ne marche pas de la même façon.
Brunelleschi a fait des dessins pour son cahier des charges. Dans l'industrie on fait du dessin industriel. En Taupe c'était avec la planche à dessin, le dessin était déterminé par la géométrie de la chose à représenter. Maintenant le dessin se fait avec des ordinateurs en CAO et ensuite on n'a plus qu'à introduire le fichier dans la machine à commande numérique. Certes on peut commettre des erreurs informatiques...
On ne peut pas dessiner un logiciel
Le dessin d'architecture est un procédé bien adapté à son objet, qui est visible et visuel, même si on peut faire des erreurs : des églises bretonnes se sont effondrées parce que le granit est plus lourd que le calcaire, et que l'on avait utilisé des plans inadaptés...
La raison fondamentale pour laquelle cette démarche échoue pour l'informatisation, c'est que le logiciel est invisible. Dans l'industrie on a des ingénieurs qui font du dessin industriel, ils dessinent la pièce avec leur logiciel CATIA ou Autocad, puis ils passent le dessin à des dessinateurs projeteurs qui en raffinent les détails, puis on l'envoie à des régleurs qui règlent les machines outils et la chose se fait. Les gens qui ont travaillé sur l'informatisation ont tenté de reproduire cette logique. Des gens conçoivent (on appelait ça des organigrammes), puis on a mis des arbres pour faire de la programmation structurée, puis on a fait Merise, puis UML. Ce sont des tentatives désespérées pour mettre en forme ce que l'on croyait être la conception, et on pensait que la programmation c'était l'équivalent de l'usine. L'idée était d'avoir des gens intelligents (les analystes, homologues des ingénieurs de la mécanique) qui conçoivent puis des exécutants bêtes (les programmeurs, homologues des ouvriers) qui programment, et ça donne le taux d'échec qu'on connaît.
Pourquoi ? Parce que le logiciel est constitué de programmes, et qu'un programme n'est pas un objet qui se déduit mécaniquement d'un dessin : sa réalisation est un art de conception, un art très difficile qui ne peut être qu'une activité artisanale. On ne peut pas industrialiser la programmation.
IBM a réalisé des ateliers tayloriens de programmation, cela n'a pas marché. La productivité est très faible : 10 à 50 LCS/mois*homme. Si le programmeur est en même temps le concepteur, on divise le temps par quatre : on économise les échanges d'information entre le demandeur et le réalisateur, qui représentent les trois-quarts du temps nécessaire à la réalisation du programme. Si on fait grossir la taille de l'équipe, on ajoute des échanges d'information entre tous ces gens, et le délai augmente, pour n participants, selon la formule
Une autre idée de conception à retenir : s'il faut neuf mois à une femme pour faire un enfant, neuf femmes ne feront pas un enfant en un mois. Pour pelleter de la terre, on peut augmenter la taille de l'équipe parce que la communication entre les pelleteurs est faible, et on sait bien qu'au bout du compte le résultat dépend de la contrainte physique exercée sur eux par un contre-maître impitoyable. Mais l'informatique est compliquée : plus on ajoute du monde, plus les gens doivent échanger de l'information compliquée, et la contrainte physique est sans espoir parce que c'est une activité intellectuelle.
La référence sur ces questions est le livre Le Mythe du mois-homme, écrit par Frederick Brooks, architecte du système d'exploitation IBM OS/360, qui sait de quoi il parle, et qui fait d'ailleurs l'autocritique des méthodes infructueuses qu'il a employées à l'occasion..
L'obstacle est intellectuel
La première condition à remplir pour une informatisation réussie est de reconnaître que la programmation est complexe, qu'elle demande de la créativité, qu'elle doit être faite par des gens de haut niveau qui ont un recul important par rapport à leur activité. Si on peut éviter de programmer, il faut le faire : mieux vaut s'adapter à un logiciel existant que de faire adapter un logiciel à des besoins précis !
Le problème des Français, c'est qu'ils sont plus intelligents que les autres (!) : là où les gens des pays ordinaires s'adaptent aux logiciels des fournisseurs, les Français demandent des adaptations spécifiques, et alors la catastrophe est assurée. On aura tous les inconvénients des progiciels et aussi ceux du logiciel spécifique.
On a dépensé 50 M€ pour un logiciel comptable et financier dans tel établissement public, et il ne marchera jamais : il faut des ingénieurs pour passer des écritures, alors qu'avec un logiciel normal on fait faire la comptabilité par des agents administratifs... Le logiciel comptable de cet établissement produit des écritures fausses qu'il faut corriger à la main. Mais la cours des comptes a trouvé ça très bien.
Pour produire un logiciel, l'organisation standard préconisée par les manuels repose sur le cycle en V : c'est une autre erreur ! C'est idiot, c'est fait partout, c'est la source de catastrophes...
Spécification, conception générale, conception détaillée, pour bien montrer que la programmation doit être faite par des esclaves on la nomme codage, puis on remonte, on fait des tests unitaires pour vérifier la conception détaillée, puis de l'intégration, puis de la recette. On a là la hiérarchie des personnels : les couches hautes sont occupées par des personnels de haut niveau, en bas c'est la piétaille.
Il faut supprimer cette organisation ! On va voir comment.
Le diagramme en V va bien pour le bâtiment : une fois qu'on a commencé à construire un bâtiment on ne va pas changer les plans. Si je construis une cabane au fond du jardin, et que je veux ajouter des étages en gardant les fondations de la cabane, ça ne va pas marcher. Si Renault conçoit un modèle d'automobile, une fois les plans faits et l'usine construite, on ne va pas dire « je ne fais plus comme ça, je change le modèle ». Une fois qu'on a fait les plans du bâtiment ou de l'automobile, ça dure. Avec le logiciel c'est différent. Pour un logiciel pas trop compliqué il faut compter trois ans entre le début de la spec et la recette. Pour un progiciel un peu compliqué il faut compter 7 ans.
Une voiture de première gamme moderne comporte 40 ordinateurs, une voiture de haut de gamme en comporte 100. Le frein envoie un message de demande de freinage à un ordinateur qui, selon l'adhérence mesurée par des capteurs, va décider si il fait un simple ralentissement ou s'il actionne le circuit hydraulique ou une combinaison des deux. La durée de conception d'une voiture c'est moins d'un an. Comment est-ce possible ? Parcequ'une grande partie du logiciel a déjà été faite, elle se trouve dans une bibliothèque standard de composants.
De même dans la banque ou dans la téléphonie mobile : les informaticiens disposent de frameworks, qui sont des plates-formes logicielles et boîtes à outils toutes prêtes, et ils font de l'assemblage de composants. Pour faire un logiciel ex nihilo c'est par contre trois ans minimum.
Si vous prenez trois ans pour faire un logiciel de RH, les besoins de la DRH auront évolué par caprice pour partie mais aussi pour des raisons réglementaires. De mon expérience, les gens qui connaissent bien la réglementation sont ceux qui développent ou paramètrent les logiciels, ils sont capables de modifier le logiciel en fonction des évolutions réglementaires.
Alors comment faire ?
Alternatives au cycle de développement en V
Il est possible de modifier un logiciel en cours de route puisque c'est de l'immatériel. Les méthodes qui ont des chances de marcher sont celles qui font de petits cycles très courts de spécification et de réalisation, sans avoir à supporter le poids de la pyramide hiérarchique. Il faut pour cela une petite équipe de gens qui travaillent dans le même bureau. Développer un logiciel à plus d'une douzaine de personnes, c'est une entreprise dangereuse.
Donc on met les spécificateurs, concepteurs etc. avec les programmeurs dans une même pièce et ils vont avancer. Les gens qui ont mis ça en place ont inventé l'eXtreme programming. C'est une méthode prometteuse, elle échappe à tous les préjugés classiques de la conduite de projet. Le grand V a toutes les chances d'échouer, il oblige à traverser toute la pyramide bureaucratique. L'idée c'est de remplacer V par vvvv avec de multiples recettes. La distance entre deux v peut être de 15 jours à deux mois.
Plutôt que de faire du top down on va faire du bottom up, des réalisations partielles mais qui marchent. Feynman, le prix Nobel de physique, a fait un rapport sur l'accident de la navette Challenger. Il a dénoncé une erreur dans la conception de la navette : elle a été faite top down et à l'arrivée c'est très complexe, le moindre changement a des répercussions sur l'ensemble... ça n'empêche pas d'avoir une vision d'ensemble, mais on ne peut plus repartir du composant élémentaire … on n'avait pas prévu qu'il pouvait faire très froid en Floride et novembre et que les joints pouvaient perdre leur élasticité. Pourtant les gens dont le travail est de concevoir des joints le savent...
eXtreme programming : on fait des choses partielles, qui marchent vite, et qui montrent à l'utilisateur ce que l'on est en train de produire. Le représentant de la MOA travaille avec les autres, dans le même bureau... Idée : une petite équipe où chaque individu a son double. Mais ça n'est pas compatible avec les marchés publics. Les marchés publics, la comptabilité publique, le statut de la fonction publique, c'est condamné, ça ne correspond pas au travail qu'il y a à faire dans le monde moderne.
Le code des marchés publics oblige à utiliser le cycle en V. Dans vvv, si le réalisateur est un prestataire extérieur, on évoque des choses qui ne sont pas encore signées au marché or le code des marchés publics l'interdit. Dans vvv on ne sait pas quand ça va finir, dans V on croit qu'on le sait. Pour maîtriser les délais, la seule solution est de prendre des logiciels qui existent déjà, mais il faut avoir développé le framework.
Avec le logiciel libre vous ne savez pas trop ce que vous voulez faire, vous téléchargez, vous essayez, vous pouvez lire la documentation, construire des maquettes et voir si cela ressemble à ce que vous cherchez. Cf. le prix du livre de l'AFISI, gestion des données de référence. Il y a des logiciels pour ça, mais j'utilise un logiciel libre. Je vais essayer un logiciel libre de MDM. Si je dois m'engager sur un logiciel payant, il faut avoir choisi avant de l'essayer. Or l'entrepôt de données est une affaire de longue haleine.
Dans la conduite de projet, on va surspécifier, introduire une entreprise d'AMO qui va faire un CDC de 3 000 pages, très cher, et ce ne sera pas ce qu'on voulait. Il ne faut surtout pas trop passer de temps à l'analyse de l'existant et au recensement des besoins. Il faut avoir une idée de ce qui existe, une idée des besoins, mais pas trop, sinon on ne fait que programmer les mauvaises habitudes, les mauvaises pratiques.
La flexibilité plutôt que les procédures
Socrate à la SNCF : il faut que des gens décident ce qu'il faut faire et qu'ils connaissent l'entreprise. Socrate a conjugué une modification technique des choses à faire et une réorganisation, on n'a pas pris assez en compte la façon dont les agents travaillent, et les agents étaient hostiles à la réorganisation. Quand une vraie entreprise décide de se réorganiser, les gens changent ; dans la fonction publique, si les gens ne veulent pas changer ils ne changent pas.
Erreur fatale : rédaction d'un schéma directeur des SI. C'est pas mal d'avoir un document d'orientation. Je l'ai fait ce matin même ! Mais sur une dizaine de pages, une vingtaine peut-être. Il ne faut pas en faire trop.
Le métier de chef de projet apparaît avec la méthode de conduite de projet. C'est bon que le projet ait un chef, mais l'idée d'un « métier » de chef de projet est à bannir. La chaire de génie logiciel au CNAM voit arriver des gens qui veulent avoir un diplôme d'ingénieur en génie logiciel et qui n'ont jamais écrit une ligne de code, ni n'envisagent une minute de s'y mettre : ils n'y comprendront jamais rien.
La règle de trois, c'est très utile. Par contre la résolution de l'équation du second degré sert peu, mais si on n'a jamais appris ça on ne peut pas comprendre ce que sont les maths. On vous l'apprend non parce que c'est utile, mais parce que ça vous aide à comprendre le travail d'un ingénieur etc.
La programmation c'est la même chose. Je milite pour introduire l'informatique dans l'enseignent secondaire à la cadence de trois heures par semaine. On écrit des programmes et on les fait marcher sur des ordinateurs. J'ai connu l'époque où l'on faisait faire un peu de Fortran à des ingénieurs, c'était nuisible parce que cela produisait des gens qui croyaient qu'ils savaient. Pour vraiment comprendre il faut avoir suivi un vrai cursus d'informatique, même élémentaire.
Grace Hopper a inventé Cobol qui s'apprend en trois jours – mais on n'apprend pas à programmer en trois jours. Beaucoup de gens ont programmé en Cobol, aujourd'hui les mêmes programment en Perl, mais personne ne sera ensuite capable d'interagir avec le programme parce que celui qui l'a écrit ne savait pas programmer. Beaucoup de programmes dans les banques ou en RH sont en Cobol. Plus personne n'est capable de les modifier pour les adapter à la réglementation, sinon en leur ajoutant des verrues.
On peut descendre dans UML à un niveau de détail qui permet de générer du code, cela devient un langage de programmation, la question à se poser alors est celle de sa qualité comme langage de programmation, et la réponse n'est pas enthousiaste. UML a une utilité, c'est qu'on peut espérer que des diagrammes UML pas trop détaillés permettent de faire comprendre quelque chose aux dirigeants quand on leur montre un schéma. Pour la spécification détaillée, UML n'est sans doute pas l'outil idéal.
Deux langages sont bons pour une initiation : Turbo pascal, qui s'appelle aujourd'hui Delphi, c'est assez démodé mais bien. Puis il y a Scheme. Granet a publié sur Java, chez Dunod, une approche dépouillée et accessible de Java pour un débutant.
Pourquoi les informaticiens sont-ils haïs ?
On les déteste, c'est un obstacle à l'informatisation de la société. Je suis entré dans la fonction publique, puis j'ai démissionné, j'ai travaillé dix ans dans le privé, puis je suis revenu.
J'ai constaté la haine envers les informaticiens. Parfois on éradique l'informatique. Les dirigeants français aiment le management du XIXe siècle, comme dans les romans de Zola : « Ouais, on va faire suer le burnou, et puis si çane marche pas on externalise tout. » C'est juste ridicule.
Externaliser un SI, ça ne veut rien dire, vous n'existez plus : si on externalise l'inscription des étudiants et les cours, l'université n'existe plus. On peut certes externaliser certaines activités bien choisies mais la haine pousse à virer tous les informaticiens, on les répartit comme esclaves dans les départements utilisateurs, les prestataires de l'externalisation sont alors les maîtres, on fait tout en Inde, ça donne finalement des résultats catastrophiques : il faut cinq ans après reconstruire l'informatique qu'on a détruite...
Pour externaliser quelque chose il faut très bien le connaître, or le SI bouge tout le temps. Le prestataire va vous imposer un contrat précis et il faudra payer des avenants lors de tout changement. Comme on veut se débarrasser des informaticiens, on n'y connaît rien, et c'est alors qu'on externalise. Les motifs de la haine : les primes pour les informaticiens dans la fonction publique, ils sont mieux payés, ils ont des carrières plus rapides, jalousie. Il y a aussi des gens qui prophétisent la fin de l'informatique : « Quand est-ce que ça va finir tout ça ». A l'Institut Pasteur, une directrice de haut niveau m'a dit : « Ca va durer combien de temps ? », et je lui ai répondu « Bien au delà de nos retraites respectives ».
J'ai eu une conversation avec le patron d'une entreprise qui crée des sites Web. Il employait 600 personnes juste avant la crise avec des filiales dans d'autres pays. Ce sont des sites Web pour petites entreprises, un développeur doit faire deux sites par jour.
« J'ai un turn over élevé parmi les informaticiens, m'a-t-il dit ; ils n'ont pas le même rythme de travail que les autres. » Tous les gens de l'entreprise ont un rythme de travail qui se mesure en jours et en semaines, piloté par des interactions avec le monde extérieur. Le commercial passe des coups de téléphone aux clients, le service comptable vit au rythme des factures et des bons de commande etc. Le marketing et la communication vivent selon un cycle court. Le service informatique par contre fait des développements où l'unité de temps est le mois.
Dijkstra a parlé de l'indice de John Buxton, professeur d'économie à l'université de Warwick : l'indice de Buxton est la durée en année de la période sur laquelle une personne ou une équipe établissent leur plan d'action. 0,5 (6 mois) pour un commercial, 5 pour un homme politique. La coopération étroite entre des personnes ou des équipes qui ont des indices de Buxton trop différents est vouée à l'échec.
Or dans une entreprise l'informatique est un métier différent avec un rythme différent. Dans l'industrie les gens différents sont séparés par la distance et le costume, alors que les informaticiens vivent dans des bureaux proches des autres.
La cohabitation proche de gens qui semblent pareils mais qui font des choses différentes, selon des rythmes différents, est un facteur de conflit.
Les risques : préretraite, faillite, sous-développement selon que l'on considère les personnes, les entreprises ou les pays.