Précédent Remonter Suivant
Page d'accueil de ce livre

Chapitre 5  Méthodes de conception, de spécification et de réalisation

Nous l'avons déjà noté, l'histoire des développements informatiques est scandée par la recherche d'une méthode miracle qui permettrait d'encadrer de façon sûre l'activité de programmation, perçue comme trop coûteuse, voire de la remplacer. Jusque dans les années 1970 on parlait de méthodes d'analyse, en opposant l'analyse à la programmation, puis la terminologie a changé, et l'on parle de méthodes de conception, de modélisation ou de spécification. En gros toutes ces méthodes ont échoué faute d'avoir vraiment compris la nature réelle de cette activité : la programmation n'est pas une fabrication, c'est un acte de conception, et des plus complexes. Cet échec n'est pas tout à fait général, nous citerons dans ce chapitre des méthodes qui ont réussi au moins dans certains cas de figure, mais nous verrons que c'est justement parce qu'elles respectent la nature de la programmation, voire qu'elles sont des langages de programmation déguisés. Parmi les méthodes qui peuvent être créditées d'une aptitude réelle à améliorer la production de logiciels, la méthode B comporte en fait un langage de programmation incorporé, on peut dire qu'elle ne fait que déplacer le niveau d'abstraction de l'activité de programmation sans la remplacer dans son rôle de conception ; eXtreme Programming est plutôt un recueil de bonnes pratiques associées à un modèle d'organisation du travail.

Dans le champ de la conception informatique, les métaphores inspirées de l'industrie mécanique ou du bâtiment sont séduisantes mais fausses, elles ont beaucoup contribué à induire en erreur des managers qui en fait ne demandaient pas mieux, aveuglés par l'agacement considérable suscité chez eux par cette activité de programmation qu'ils ne comprenaient pas, et plus encore par ceux qui la pratiquaient.

Ce chapitre présentera à titre d'exemples un certain nombre de méthodes de conception, sans prétention à l'exhaustivité ni à un classement ; le chapitre suivant exposera quelques problèmes soulevés par le travail avec les informaticiens, population aux caractéristiques un peu particulières.

1  Méthodes ancestrales

Les plus anciennes méthodes de conception peuvent être illustrées par SADT dans le monde anglo-saxon ou Merise en France --- SADT succédait à SA, et Merise à Warnier. Elles s'inscrivent dans le cadre du cycle de développement en V que nous avons décrit au chapitre 2 et dont nous reproduisons ici le schéma de principe.

Figure 5.1 : Cycle de développement « en V » du logiciel, inspiré des industries de production matérielle.

Ces deux méthodes reposent sur l'erreur fondamentale selon laquelle l'activité de conception s'arrêterait à la rédaction du cahier des charges et des spécifications détaillées, d'où le texte du programme se déduirait pour ainsi dire mécaniquement, ou en tout cas sans ambiguïté ni complexité majeure. Elles font donc porter l'essentiel de l'effort de leurs adeptes sur la précision et la clarté des documents de définition et de spécification du projet, avec le risque qui en découle (et souvent réalisé) d'un projet sur-spécifié.

Il y a dans ces méthodes, surtout dans Merise, un effort touchant pour éduquer le disciple. Il est vrai que les chefs de projet informatiques n'ont pas forcément été les meilleurs de la classe en philosophie. Essayer de leur enseigner les rudiments d'une pensée systématique n'est donc sans doute pas tout à fait inutile et, s'ils en retiennent quelques leçons tirées du Discours de la Méthode de Descartes, l'effort n'aura pas été vain. On constatera d'ailleurs avec étonnement que dans cet exercice les auteurs américains se révèlent souvent de meilleurs disciples de Descartes que ses compatriotes.

Ces méthodes sont assez ennuyeuses, et ont en outre fait la preuve d'une aptitude modérée à atteindre l'objectif qu'elles se proposaient. Nous dirons néanmoins quelques mots de deux d'entre elles, Merise et SADT, parce que, si l'on renonce à construire un modèle complet de l'entreprise, et que l'on se contente d'un usage raisonnable, sans visée totalisante, elles peuvent donner des résultats utiles en facilitant la communication entre acteurs de cultures différentes. Nous pourrions d'ailleurs en dire autant d'à peu près toutes les méthodes disponibles.

Merise

La méthode Merise a été inventée en 1978 par une équipe du CTI (Centre Technique d'Informatique) et du CETE (Centre d'Études Techniques de l'Équipement) d'Aix-en-Provence animée par Hubert Tardieu, Arnold Rochfeld et René Colletti à la suite d'un appel d'offres du ministère français de l'industrie. Elle se propose pour les activités de conception, de développement et de réalisation de projets informatiques, avec comme objectif la constitution d'un système d'information. Elle repose sur la séparation des données et des traitements, et sur la construction de modèles conceptuels, logiques et physiques de données, ordonnés au moyen du modèle entité-relation.

La concepteur Merise va entreprendre de construire un modèle fin du fonctionnement de l'entreprise, mais auparavant il lui faut en tracer les grandes lignes. Pour ce faire il va en identifier les acteurs internes, ou domaines, puis les flux d'information entre ces domaines. La description de cette charpente de l'entreprise va permettre de travailler domaine par domaine pour construire la représentation détaillée du système tel qu'il existe au départ de la démarche. Armé du modèle entité-relation, le concepteur Merise va décrire le fonctionnement de l'entreprise et de son système d'information.

Le modèle entité-relation

Le formalisme entité-relation est une norme ISO destinée à la description des aspects conceptuels statiques des données pour les systèmes d'information. Il n'est pas propre à Merise et il est utilisé avec d'autres méthodes telles qu'AXIAL ou SADT.

Les entités sont des regroupements d'informations, qui pourront par exemple être représentés par une classe du modèle objet et comporter des attributs : ainsi l'entité être-humain sera dotée des attributs nom, prénom, sexe, âge, etc.

Les relations établissent des liaisons logiques entre les entités : ainsi une entité de la classe être-humain peut avoir une relation de type être-propriétaire-de avec une entité de la classe automobile. Une relation peut être factuelle comme être-propriétaire-de, ou dynamique comme acheter. Une propriété importante des relations est leur cardinalité : la relation être-mère-de est de cardinalité 1:n (une femme peut être mère de 0, 1 ou plusieurs enfants), cependant que la relation avoir-pour-mère est de type 1:1, chaque être humain a une mère et une seule.



Il est bon qu'une entité possède un identifiant, c'est-à-dire un attribut ou un groupe d'attributs qui permettent de l'identifier de manière unique. Les lecteurs familiers des bases de données voient que Merise utilise des notions assez voisines de l'algèbre relationnelle, et peut se prêter à la description d'une base de données fondée sur ces principes.

Le conseil souvent donné, et judicieux, pour le choix d'un identifiant, est d'éviter de prendre des attributs significatifs, et au contraire d'attribuer à l'entité un identifiant numérique dépourvue de toute signification. On évitera ainsi le risque de modification d'un attribut servant d'identifiant parce que la réalité sous-jacente aura changé. Ainsi le numéro INSEE, dit « de sécurité sociale », est un mauvais identifiant : un étranger qui arrive sur le sol français est doté d'une immatriculation provisoire et ne connaît son numéro définitif que plusieurs mois plus tard ; et aujourd'hui il y a des personnes qui changent de sexe, phénomène que les statisticiens des années 1940 n'avaient pas envisagé.

Modélisation du Système d'Information

Après avoir recensé toutes les entités de l'entreprise, le graphique obtenu en traçant leurs relations constitue le Modèle Conceptuel de Données (MCD), duquel le concepteur Merise va déduire le Modèle Physique de Données (MPD) au moyen d'un certain nombre de règles logiques :
  1. [Règle n° 1 : ] toute entité est représentée par une table ;
  2. dans le cas d'entités reliées par des associations de type 1:1, les tables auront le même identifiant ;
  3. dans le cas d'entités reliées par des associations de type 1:n, chaque table possède son propre identifiant, mais l'identifiant de l'entité côté 1,n est recopiée vers la table côté 1,1 et devient un identifiant étranger (index secondaire : chaque individu a comme attribut l'identifiant de sa mère, ce qui permet de retrouver rapidement tous les enfants d'une même femme) ;
  4. dans le cas d'entités reliées par des associations de type n:m, une table intermédiaire dite table de jointure, est créée, et possède comme identifiant primaire une conjonction des identifiants primaires des deux tables pour lesquelles elle sert de jointure ;
  5. etc.
Tout cela semble très satisfaisant pour l'esprit. Il y a juste une objection à formuler : cette activité de modélisation est entièrement informée par l'analyse de l'existant, et pas du tout par l'énonciation des objectifs que le système informatique projeté est destiné à atteindre. La méthode Merise postule que cet objectif se déduit implicitement de la modélisation de la totalité de l'entreprise, ou du domaine concerné de l'entreprise. Nous verrons au chapitre 7 que cette façon d'élaborer un système d'information est utopique, elle suppose que la nature et le sens de l'information stockée par le SI sont des éléments objectifs de la réalité, indépendants du but poursuivi. En fait, comme nous l'apprend la Field theory of information dont nous avons parlé à la page ??, une donnée ne devient une information que par l'interprétation qui en est faite, et celle-ci dépendra profondément de celui qui la fait, de ses objectifs et aussi de la date à laquelle il la fait --- pour approfondir ces questions on se reportera avec profit aux travaux d'Isabelle Boydens[17] et de Michel Volle[120]. Forts de ces enseignements, nous pensons que la construction d'un système d'information aura quelque chance de succès si sa conception est fonction d'un objectif précis, ce qui veut dire qu'au lieu de recenser toutes les entités que l'on trouve dans l'environnement, il faut au contraire choisir de la façon la plus restrictive possible celles qui vont être utiles. Les adeptes de Merise pourront objecter que rien dans leur méthode ne s'oppose formellement à une telle démarche : sans doute, mais tout dans l'exposé de la méthode et dans la tradition de son usage pèse sur le plateau du « Système d'Information global de l'entreprise », et d'ailleurs le bilan des expériences réelles de l'application de Merise confirme cette tendance.

On aura aussi remarqué que la méthode Merise est fort diserte sur l'architecture des données, mais très discrète sur les traitements. De même, les moyens proposés semblent assez puissants pour modéliser les données, mais beaucoup moins pour ce qui a trait à leurs évolutions dans le temps.

Pour conclure au sujet de Merise, on peut dire que modéliser le fonctionnement de son entreprise est un exercice profitable, à condition de ne pas y passer trop de temps et de ne pas descendre trop dans les détails ; dans cette optique une application modérée de Merise peut être utile pour clarifier des processus délicats dont l'importance justifie une telle analyse. Mais soumettre l'ensemble des processus à une telle revue de détail est d'autant plus inopportun que les sommes considérables qui seront englouties dans cette opération n'ont aucune chance de déboucher sur un système d'information global utile, et ce pour les raisons déjà exposées : l'information n'a pas d'existence objective, en soi, elle doit être construite au moment où on en a besoin, et en fonction de ce besoin précis, qui commandera sa nature. Le chapitre 7 expliquera plus en détail pourquoi cette idée de système d'information global est vouée à l'échec. Cette promesse d'échec concerne encore plus les SI « décisionnels » constitués par extraction, à partir des bases de données destinées à la gestion quotidienne, d'informations « stratégiques » à l'usage des dirigeants : non seulement on interprète dans un certains contexte des données élaborées dans un tout autre contexte et pour d'autres motifs, mais en outre on réalise un vaste cocktail de données totalement hétéroclites (voir à ce propos la page ??). Bien sûr aucun véritable dirigeant n'utilise ce genre de chose, mais dans les grands groupes bureaucratisés cela se pratique. On trouvera sur le site de Michel Volle un exemple[115] qui contredit en partie notre propos : il s'agit de la création, dans une grande entreprise non totalement exempte de bureaucratie, d'un tableau de bord à l'usage du comité de direction ; l'expérience a réussi, mais non sans en passer par un travail très important de ré-élaboration des données, sur lequel nous aurons à revenir.

Alors que des méthodes telles que B ou eXtreme Programming sont explicitement dévolues au développement de logiciel, une méthode comme Merise prétend viser un objectif qui serait plus élevé et plus vaste, la conception d'un système d'information. Une telle prétention est largement fallacieuse : concevoir le système d'information n'est d'aucune utilité si l'on échoue à concevoir les logiciels sans lesquels il n'existera pas, or là Merise se révélera dans bien des cas un obstacle plutôt qu'une aide. On pourrait dire de Merise ce que nous avons écrit plus haut d'ISO 9000 : un usage modéré pour des objectifs limités à une vision d'ensemble de l'organisation peut se révéler utile, mais la généralisation systématique pour des usages opérationnels risque d'être catastrophique.

Aujourd'hui René Colletti a modifié son point de vue[80] : après avoir préconisé la modélisation à tout crin du SI, il conseille désormais de le détruire au bulldozer ! Un tel discours est évidemment séduisant pour les directeurs généraux, parmi lesquels la pulsion à la mode est de mettre leur DSI à la porte, si possible accompagné d'une abondante charrette de ses collaborateurs. Colletti se place sur ce marché : selon lui, il faudrait maintenant faire appel à « des techniciens d'audit, qui expertisent les systèmes d'information ; des consultants, qui déterminent ce qui est bon et ce qui ne l'est plus ; des experts des métiers, qui en fixent les enjeux ; des ``traducteurs'', qui traduiront ces enjeux en termes informatiques, etc. ». Pour ma part je ne trouve aucune des deux positions très convaincante.



Structured Analysis and Design Technique (SADT)

SADT1 est une méthode de modélisation, de conception et de spécification mise au point en 1976 sous la direction de D.T. Ross, de la société américaine SOFTECH, à partir d'une collaboration avec ITT. C'était la belle époque de la programmation structurée, et SADT en est imprégnée.

La méthode ne manque pas de points communs avec Merise, dont elle est à peu près contemporaine, mais elle est dépourvue de son ambition globale et paraît de ce fait plus pragmatique : il s'agit d'aider les concepteurs à modéliser une activité et les entités qu'elle concerne afin de concevoir et de spécifier une application informatique, et il n'y est pas question de système d'information.

SADT pose en principe le cycle de développement en V, que nous avons critiqué à la page ?? : on établit des spécifications détaillées immuables avant d'attaquer la programmation. La méthode partage ici les erreurs issues du parallèle entre l'informatique et les industries de production mécanique ou de construction, et concerne uniquement les étapes qui précèdent le développement.

L'idée est de faciliter la modélisation et la conception par une standardisation d'un certain nombre de documents : tableaux, diagrammes et graphiques, dont la présentation uniforme et systématique codifiée par une véritable syntaxe graphique aide les membres de l'équipe de projet à s'y retrouver. De ce point de vue, l'adoption de telles conventions est peut-être judicieuse --- mieux vaut une méthode que l'anarchie et le désordre --- mais l'expérience tend à prouver que la confection de tels documents est si ennuyeuse que les développeurs ne les mettent pas à jour lorsqu'ils modifient les programmes, qu'ainsi ils deviennent faux, et donc nuisibles.

Il est possible d'utiliser le formalisme entité-relation avec SADT.

La méthode comporte aussi des recommandations en termes de composition et d'organisation de l'équipe de projet, avec notamment une procédure dite cycle auteur/lecteur qui consiste en une transposition aux étapes de spécification de la pratique des revues de code qui existaient déjà (mais sans être assez pratiquées !) pour les étapes de développement. Comme le nom le suggère, il s'agit de soumettre un kit, c'est-à-dire un paquet de documents SADT censés représenter la spécification d'une partie de l'application, réalisé par un membre de l'équipe, à l'analyse critique d'autres membres de l'équipe.

Pour conclure au sujet de SADT, si l'on met entre parenthèses le cycle de développement en V, franchement rédhibitoire, il y a sans doute quelques bonnes idées à en retirer, dans la mesure où l'adoption de procédures méthodiques, quelles qu'elles soient d'ailleurs ou presque, introduit un progrès par rapport au désordre spontané, mais rien de décisif pour franchir la barrière du développement logiciel. Bref, ce n'est pas nuisible, mais pas non plus franchement utile.

2  Tribut à Frederick P. Brooks Jr.

Frederick P. Brooks Jr fut au début des années 1960 un des principaux concepteurs de l'OS 360, le système d'exploitation des mainframes IBM, et le chef de projet de sa réalisation. Il convient de signaler qu'en 2004 le descendant de ce système est toujours utilisé à grande échelle et repose toujours sur la même conception. Il s'agit donc de l'un des plus gros et des plus longs projets de l'histoire de l'informatique, ce qui n'empêche pas son auteur de jeter un regard (auto-)critique sur la plus ambitieuse entreprise d'ingénierie des cinquante dernières années : l'écriture des systèmes d'exploitation.

En 1975 Brooks a écrit un livre[19] intitulé « Le mythe de l'homme-mois », où il tire les leçons d'une vaste expérience qui, de simple programmeur, l'avait conduit à la tête d'un gigantesque projet. En 1995 il en a publié une « édition du vingtième anniversaire », considérablement augmentée de réponses aux objections que lui avait values l'édition initiale, et de nouveaux développements inspirés par l'évolution technique, sociale et intellectuelle de l'informatique pendant cette période.

Quiconque possède la moindre expérience du développement informatique ne peut qu'être frappé par la profondeur et la finesse des observations et des analyses de Brooks, dont la plupart n'ont pas pris une ride malgré les bouleversements du monde informatique. Ce praticien n'a jamais l'oeil aussi sûr que pour analyser ses propres erreurs, et l'on constate en le lisant que l'on peut à la fois être un homme de terrain et posséder une vaste culture. Au-delà de quelques phrases lapidaires qui ont frappé ses contemporains (« si une femme peut faire un enfant en neuf mois, neuf femmes peuvent-elles le faire en un mois ? », « lorsqu'un projet a pris du retard, ajouter du personnel à l'équipe ne fait qu'augmenter le retard »), il se livre à une analyse détaillée de l'activité de programmation, de sa nature intellectuelle et de la manière de mener un projet, analyse nourrie de multiples exemples concrets. Il est le précurseur des méthodes modernes que nous évoquerons ci-dessous, et il n'a jamais cru à des inepties comme le cycle de développement en V. En ces temps où les informaticiens réels sortent du tunnel de vingt ans de gestion de projet et de dévaluation systématique de leur activité par des managers dont la morgue n'égale que l'incompétence, il est salubre de relire ce livre pour oser penser que ces méthodes qui leur ont été imposées étaient non seulement désagréables mais ineptes, ce qu'a démontré à l'envi une avalanche de catastrophes dont seul le secret a pu dissimuler l'ampleur. Nous ne saurions bien sûr nous dissimuler que les informaticiens ne sont pas totalement innocents de leurs malheurs, et qu'aux temps de leur splendeur, qui dans certaines entreprises durent encore, ils ont abusé sans vergogne de leur pouvoir, créant par là les conditions d'un retour du bâton, selon un expression imagée.

Un point intéressant à noter, c'est que le projet qui constitue la principale expérience de Brooks, l'OS 360, fut aussi un grand chantier d'application des méthodes industrielles à la réalisation de logiciel. Que l'un des principaux responsables du projet en vienne à écrire un livre, à la dimension autocritique explicite et assumée, qui analyse de façon détaillée les raisons pour lesquelles ces méthodes ne conviennent pas, me semble une contribution de poids à la critique de la taylorisation informatique.

J'ignore s'il a été le premier, mais en tout cas Brooks fut un des premiers à proclamer clairement qu'il est illusoire de prétendre établir au début d'un projet un cahier des charges et des spécifications immuable dont la maîtrise d'oeuvre devra assurer docilement la réalisation fidèle. Il explique que le plus difficile dans une telle entreprise consiste à définir le but à atteindre, et que l'on ne peut y arriver que par itérations successives : réalisation d'un prototype sommaire, que l'on montre au donneur d'ordres, qui fait part de ses critiques et de ses suggestions à partir desquelles sera réalisé un second prototype plus élaboré, et ainsi de suite, pendant tout le cycle de vie du système, en fait.

En praticien consommé et en observateur assidu, Brooks a noté que dès lors que l'écriture d'un programme n'est pas effectuée par une personne unique qui en a eu l'idée, mais qu'un groupe de demandeurs s'adresse à un groupe de réalisateurs, les trois quarts du temps cumulé qu'ils vont consacrer ensemble à définir et à construire le programme seront consacrés à des échanges d'information entre eux. C'est notamment pour cela qu'ajouter du personnel à l'équipe d'un projet en retard ne fait qu'accroître le retard : il faut former et informer les nouveaux arrivants, et cela prend du temps qui s'ajoute à celui que les développeurs consacraient déjà à la communication au sein de l'équipe, beaucoup plus de temps que pour l'équipe de balayeurs de couloir auxquels certains managers aiment bien comparer les programmeurs. « Les hommes et les mois ne sont interchangeables que lorsqu'une tâche peut être divisée entre plusieurs travailleurs sans réclamer de communication entre eux. »

En s'inspirant d'une idée de Harlan Mills, Brooks préconise une organisation de l'équipe de développement selon le modèle d'une équipe chirurgicale dans un bloc opératoire : de même que seul le chirurgien en titre manie effectivement le bistouri, dans une telle équipe seul le chef-programmeur écrit effectivement des lignes de code, ou si d'autres membres de l'équipe en écrivent, c'est sous son étroite responsabilité. Il est assisté d'un adjoint (le « copilote »), pourvu des mêmes compétences que lui, en général plus jeune, avec qui il s'est concerté pendant les phases préparatoires, qui assiste à toutes les phases de son travail, notamment dans les phases de conception, mais s'il écrit du code c'est sous la responsabilité du chef-programmeur. Typiquement, l'adjoint du chef-programmeur le représente dans certaines réunions de projet et peut le remplacer en tant que de besoin, c'est son alter ego. L'équipe du chef-programmeur est encore complétée par d'autres fonctions assurées par des spécialistes dont certains ne seront éventuellement pas employés à plein temps, qui pourront contribuer à plusieurs projets, et dont voici l'effectif complet type : Même si cette organisation paraît fort raisonnable, je doute qu'elle ait été beaucoup utilisée pour des projets informatiques, ce à quoi une collègue me rétorquait un jour qu'il n'y avait que pour l'informatique que cette méthode n'était pas employée, alors qu'il s'agissait du modèle standard d'organisation des équipes de conception et de développement dans tous les autres domaines d'ingénierie. Mais ne s'agit-il pas d'un trait archaïque des industries de fabrication ? Depuis la première édition du livre de Brooks sont apparus de multiples outils informatiques d'aide au développement qui remplacent au moins partiellement des assistants humains : gestionnaires de version, gestionnaires de configuration, outils de documentation et de publication, débogueurs graphiques, etc. Le WWW et les forums en ligne se révèlent de formidables moyens d'assistance technique : je sélectionne avec ma souris le message d'erreur que vient de m'envoyer mon logiciel (compilateur ou autre), je le colle dans la fenêtre de Google, et bien souvent j'ai la réponse, voire des dizaines de réponses, avec en prime l'adresse électronique d'experts dont j'ignorais jusqu'à l'existence. Ce n'est pas une démarche intellectuelle très académique, mais elle a le mérite de l'efficacité, avec cette restriction qu'elle fonctionne surtout pour les logiciels libres. C'est ainsi que les informaticiens améliorent leur productivité, et non pas avec des méthodes tayloriennes.

Fort de ses années de pratique, Brooks nous livre une remarque qui pourrait sembler anecdotique, mais qui en réalité touche au coeur de la question : rédiger des cahiers des charges et des documents de spécification et les présenter à des comités de projet au cours d'interminables réunions, c'est extrêmement ennuyeux et démobilisateur. Écrire un programme qui tourne, même s'il ne fait presque rien, est une activité exaltante, non seulement pour le programmeur, mais aussi pour toute l'équipe et pour le maître d'ouvrage, qui se trouvent galvanisés de voir les choses avancer concrètement. Il faut donc réduire au minimum les activités démobilisatrices dans lesquelles le projet va s'enliser, et multiplier les occasions de s'enthousiasmer pour une activité créatrice, dans les limites des objectifs poursuivis bien entendu.

En effet, et c'est en réalité assez mystérieux, mais quiconque a programmé, ne serait-ce qu'un peu, le sait, réussir à faire marcher un programme procure une sensation intense d'allégresse, totalement disproportionnée à l'enjeu réel du programme, qui peut être un exercice minuscule, et en revanche aller se coucher tard dans la nuit sans avoir réussi à résoudre un problème de programmation laisse un arrière-goût de découragement tout aussi excessif. Trouver la solution d'un problème de mathématiques ne procure pas d'émotions aussi violentes. Même des psychologues de la programmation comme Gerald Weinberg[124] n'ont pas vraiment élucidé ce phénomène.

Brooks et Weinberg sont d'accord pour préconiser une « programmation sans ego » : tout acte de programmation est en fait un acte social, puisque tout programme a vocation à être généralisé et partagé. L'abnégation de l'auteur contribuera à rendre ce partage plus facile et plus large. Cette vision évoque une morale un peu naïve, mais on aurait tort de la négliger, elle est effectivement au coeur de l'acte du programmeur, et c'est elle qui explique en grande partie le développement considérable du mouvement du logiciel libre. Et c'est faute de l'avoir comprise que nombre de managers extérieurs au monde de la programmation ont fait échouer des projets informatiques pour lesquels ils croyaient avoir choisi de bonnes méthodes qui n'étaient en fait que des mécanismes autoritaires déguisés mais inefficaces et promptement déjoués par les programmeurs indignés. En termes plus directs, si l'on persécute les programmeurs avec Merise et ISO 9000, on s'expose à un sabotage bien mérité.



3  Méthode B

Jusqu'ici notre propos a été plutôt sceptique à l'égard des méthodes systématiques de conception et de spécification, et nous avons eu l'occasion de signaler (page ??) la séparation presque totale entre le monde des développeurs de logiciel et celui des théoriciens de la preuve de programmes.

Il est des circonstances où le scepticisme doit battre en retraite et où la spécification formelle et vérifiable du logiciel est un impératif indubitable. Nous n'admettrions pas que la validité du logiciel qui pilote les rames de la ligne 14 du métro parisien, dépourvues de conducteur, soit abandonnée au hasard d'une découverte empirique des erreurs. Avoir un accident d'auto parce que le logiciel qui contrôle le dispositif de freinage s'est trouvé dans un état non vérifié nous semblerait inacceptable, et il en va de même pour les avions, les centrales nucléaires et toutes sortes d'autres matériels, dont les systèmes informatiques de pilotage et de contrôle sont en général désignés par la locution informatique technique, et que nous avons rangés dans la classe 2 définie par notre introduction page ??. Le présent ouvrage n'est pas vraiment consacré à ce type de systèmes, mais nous décrirons brièvement ici une méthode de construction de programmes qui, sans leur être exclusivement dédiée, est surtout employée à leur intention.

Les systèmes informatiques industriels sont développés dans un contexte très différent de celui qui prévaut pour l'informatique de gestion. Pour les systèmes de gestion (la classe 1 de la typologie des systèmes évoquée dans notre avant-propos page ??) les demandeurs sont des gestionnaires, population généralement peu motivée par la compréhension des problèmes techniques. Il est en outre frappant de constater, dans le domaine de la gestion, que, si les équipes du maître d'ouvrage sont souvent insuffisamment compétentes --- ce qui n'est guère surprenant2 --- les équipes des sociétés de service qui interviennent sont constituées de personnels dont les diplômes en informatique sont pour le moins modestes, voire inexistants. En informatique industrielle demandeurs et réalisateurs sont tous des ingénieurs, ce qui imprime à leurs relations mutuelles un caractère très différent de ce que l'on observe en informatique de gestion.

Si de surcroît le système informatique industriel à réaliser comporte des propriétés critiques, comme dans les exemples cités ci-dessus, les budgets et les délais vont être d'un autre ordre de grandeur, ce qui étend le champ des possibilités techniques.

La méthode B[2, 9] a été inventée par Jean-Raymond Abrial au milieu des années 1980 pour développer des logiciels prouvés. Elle a été utilisée dans le cadre du projet de métro sans conducteur METEOR réalisé par Matra (maintenant Siemens Transportation System) pour le compte de la RATP, pour construire de façon sûre les parties du logiciel qui jouent un rôle critique pour la sécurité des passagers. La partie du logiciel du métro METEOR réalisée grâce à l'Atelier B (l'outil informatique sous-jacent à la méthode[26] développé par la société ClearSy) comprend près de 100 000 lignes de code Ada générées automatiquement. Notons qu'avant B Abrial avait créé le langage de spécification Z.

Les premières démarches de preuve de programme tentaient d'appliquer des procédures de preuve à des programmes déjà construits. Il s'est assez vite révélé qu'un programme final était un objet beaucoup trop complexe pour être soumis d'un seul coup à une procédure de preuve, manuelle ou à plus forte raison automatique. L'idée de B est donc d'élaborer la preuve en même temps que le programme. Le langage de développement B permet de spécifier d'une part le programme proprement dit, d'autre part les propriétés que l'on souhaite lui voir respecter. Le manuel de référence de l'atelier B, disponible sur le site, donne l'explication suivante :

« L'écriture d'un programme B consiste à rédiger les spécifications formelles de machines abstraites à l'aide d'un formalisme mathématique de haut niveau. Ainsi, une spécification B comporte des données (qui peuvent être exprimées entre autres par des entiers, des booléens, des ensembles, des relations, des fonctions ou des suites), des propriétés invariantes portant sur ces données (exprimées à l'aide de la logique des prédicats du premier ordre), et enfin des services permettant d'initialiser puis de faire évoluer ces données (les transformations de ces données sont exprimées à l'aide de substitutions). L'activité de preuve d'une spécification B consiste alors à réaliser un certain nombre de démonstrations afin de prouver l'établissement et la conservation des propriétés invariantes en question (par exemple il faut prouver que l'appel d'un service conserve bien les propriétés invariantes). La génération des assertions à démontrer est complètement systématique. Elle s'appuie notamment sur la transformation de prédicats par des substitutions. »

On aura compris que B est un système de développement complet, qui comporte son propre langage de programmation, ce qui confirme en fait l'idée qu'une méthode de spécification est soit un langage de programmation, soit inutile, et que de toute façon la création d'un système informatique demande une vraie compétence en programmation. Il n'y a pas de magie possible. Il semble clair que les exigences de B en termes de délais et de qualification technique du personnel sont relativement élevées par rapport à du développement classique de logiciel non critique. Le tout est de ne pas se tromper dans la détermination de ce qui est critique et de ce qui ne l'est pas.

Le développement avec l'atelier B des 100 000 lignes de code Ada critique pour le logiciel du métro METEOR a engendré 30 000 obligations de preuve, dont plus de 90% ont été réalisées automatiquement. Les quelque 2 500 preuves qui ont résisté aux procédures automatiques ont nécessité plusieurs mois de travail humain, mais l'industriel a estimé que le bilan était largement positif grâce à l'économie engendrée par la suppression des tests de bas niveau. Après quelques années d'exploitation sans incident notable, la conclusion s'impose que la méthode B est efficace et sûre pour les développements critiques.

Pour être complet il faut également signaler les limites de la méthode B :

4  Unified Modeling Language (UML)

UML est un langage de modélisation[81] et de conception de systèmes informatiques, plus particulièrement adapté à la programmation par objets (voir section2). Il est né en 1997 du rapprochement de plusieurs méthodes inventées par de fortes personnalités : Grady Booch[13], qui s'était illustré de façon brillante dans le domaine des développements en Ada avant d'élargir son activité à d'autres langages, Jim Rumbaugh, auteur principal d'OMT (Object Modeling Technique) et Ivar Jacobson, créateur des cas d'utilisation (use cases) et d'OOSE (Object-Oriented Software Engineering method).

Ce qui a déclenché l'éclosion entre la fin des années 1980 et le milieu des années 1990 d'une cinquantaine de méthodes de modélisation par objets, dont UML est un aboutissement, c'est la constatation du hiatus entre les avantages techniques de la programmation par objets, qui ne sont plus guère contestés, et les difficultés de sa mise en oeuvre. En effet, aussi étrange que cela puisse paraître, les développeurs éprouvent plus de difficultés à analyser un problème informatique en termes d'objets qui interagissent qu'à le décomposer en fonctions et en données élémentaires. Or l'approche objet nécessite une grande rigueur dans la description de l'univers à modéliser et dans l'emploi des concepts, faute de quoi le risque d'échec est grand --- cela est vrai de toute approche de la programmation, mais se manifeste d'autant plus avec la démarche par objets que celle-ci se veut plus exigeante intellectuellement. Et c'est pour pallier l'absence de méthodologie standard de modélisation d'une application avec des objets qu'ont été élaborées les méthodes qui ont finalement convergé pour donner UML. En prime, UML offre bien sûr l'espoir sans cesse renaissant de permettre enfin une division du travail réussie entre concepteurs (du modèle) et réalisateurs (du logiciel) : le lecteur parvenu à ce point de notre ouvrage ne sera pas surpris d'apprendre que de ce côté-là, pour les raisons fondamentales déjà évoquées à de nombreuses reprises, la déception risque d'être de mise, mais cela ne retire pas forcément toute utilité à UML.

UML, normalisé par l'OMG (Object Management Group), est à la fois un langage de modélisation, un support de communication et un cadre méthodologique. C'est un langage formel défini par un métamodèle qui décrit de manière précise tous les éléments de modélisation (les concepts véhiculés et manipulés par le langage) et la sémantique de ces éléments (leur définition et le sens de leur utilisation).

UML se présente comme un métalangage par rapport aux langages de programmation, il repose sur une notation graphique indépendante des langages de programmation qui donne à chaque concept objet une représentation particulière, au moyen de neuf types de diagrammes qui sont autant de vues mutuellement cohérentes sur le même modèle : La confection de ces diagrammes3 au moyen d'un outil UML adéquat tel que Rational Rose permet de générer automatiquement le code qui correspond aux diagrammes, au choix en Java, C++ ou Visual Basic. Nous voici donc ramenés à un langage de programmation graphique.
Un langage de programmation graphique soulève deux types d'objections : Les vrais développeurs ont le plus souvent tendance à considérer UML comme une gêne, une entrave et un moyen de produire des documents qui ne seront pas mis à jour, et qui seront donc faux et de ce fait nuisibles.

Reste à résoudre un problème : lorsqu'un demandeur s'adresse à un réalisateur pour lui demander de réaliser un logiciel, il faut bien trouver un moyen de décrire ce logiciel. Il est possible de considérer UML comme une étape de la programmation, antérieure au « codage » proprement dit : il s'agit de bien classer ses idées avant de commencer à coder --- ce qui n'exclut pas, bien sûr, les itérations ultérieures face aux difficultés du codage. De ce point de vue, la modélisation est un moment de l'activité de programmation, elle est effectuée par les mêmes personnes que le codage, mais lors de périodes de temps différentes.

Un usage modéré et non dogmatique d'UML pourra peut-être aider au démarrage d'une activité de conception ; la méthode eXtreme Programming examinée à la page ?? propose des solutions peut-être complémentaires ou plus prometteuses.

Ne quittons pas UML sans mentionner son dernier défaut (mais non le moins gênant) : c'est, comme nous l'avons dit, une norme publiée par l'OMG, et pour avoir accès au dernier état de la norme il faut être membre de l'OMG, c'est-à-dire payer une cotisation. Nous aurons l'occasion d'y revenir plus loin dans ce chapitre, faire payer l'accès à une norme est contre-productif, cela ne fait que dissuader les gens de s'y conformer. Rendre un outil de développement payant, et a fortiori cher, c'est en détourner l'immense population de développeurs indépendants, de PME et d'étudiants qui sont aujourd'hui la force vive du développement logiciel.



5  Méthodes agiles : eXtreme Programming

La méthode eXtreme Programming[20] (XP en abrégé) se situe dans la lignée des méthodes de développement rapide ou de prototypage rapide tout en s'en distinguant, on peut dire aussi qu'elle est l'héritière des idées de Brooks, que nous avons rappelées plus haut. Elle a été créée à la fin des années 1990 par Kent Beck, Ward Cunningham et Ron Jeffries. Les auteurs du livre cité en référence l'ont introduite en France au début de notre siècle. Cette méthode et d'autres assez semblables sont maintenant appelées « méthodes agiles ».

Un développement conforme à la méthode eXtreme Programming (nous dirons « développement XP ») obéit à un cycle en V qui paraît assez semblable à celui que nous avons critiqué plus haut, mais au lieu de partir d'un cahier des charges monumental et immuable et de parcourir une fois le cycle en deux, trois ou quatre ans, on part d'une définition d'objectif très générale et laconique, en fait des scénarios établis par le client, et on va parcourir de nombreuses fois le cycle au cours d'itérations dont chacune pourra durer un laps de temps aussi bref que deux ou quatre semaines. Chaque itération amènera une définition plus affinée de l'objectif et un accroissement des capacités du système, étant entendu que dès la fin de la première itération le système sera opérationnel, même s'il ne fait à peu près rien. La durée de l'itération doit être fixée au départ ; une fois qu'elle est fixée il est important de la respecter et de procéder à chaque fin de cycle aux opérations de réception des travaux accomplis pendant cette période. L'intérêt de la méthode, on le comprend, réside dans la définition progressive mais néanmoins rigoureuse de l'objectif, et dans la capacité à s'adapter aux changements de cap en cours de navigation.

eXtreme Programming repose sur un certain nombre de pratiques XP canoniques : À ces préceptes il convient d'ajouter un style particulier de relation avec le client. Précisons tout de suite cette notion de client : idéalement ce sera le vrai client, celui qui paie, mais comme la méthode XP suppose sa présence assidue au sein de l'équipe de développement et sa participation active tant à la rédaction des scénarios qu'à la réalisation des tests de recette, dans la réalité il ne sera pas toujours possible de satisfaire à cette condition, et le rôle du client pourra par exemple être tenu par ce que l'on appelle en gestion de projet la maîtrise d'ouvrage déléguée4. La méthode précise les droits du client : XP suppose un travail d'équipe très fusionnel : tous les membres de l'équipe, y compris le client, doivent être dans le même bureau, où les postes de travail seront disposés de telle sorte que chacun puisse voir l'écran de chacun (les manuels donnent le plan conseillé pour le bureau).
La méthode définit aussi des rôles XP : Nous avons déjà défini le rôle du client ; s'il doit cumuler son rôle avec un autre, ce ne peut être que celui de testeur.

Le manager est en fait généralement extérieur à l'équipe proprement dite. Il est le supérieur hiérarchique des programmeurs et peut leur demander des comptes, notamment sur les calendriers et les budgets. S'il doit ajouter un autre rôle au sien, ce ne peut guère être que celui de traqueur.

Le coach, à l'inverse du manager, appartient pleinement à l'équipe, il en est même la cheville ouvrière, il veille à ce que chacun joue bien le rôle qui lui est dévolu et respecte les pratiques XP, il aide le client à rédiger des scénarios.

La littérature XP ajoute à ces principes un adage moins formel mais important néanmoins : le principe « diviser pour régner » est d'une grande efficacité face à un ennemi, il est contre-productif et totalement hors de propos vis-à-vis de sa propre équipe.

On l'aura compris, XP est moins une méthode de conception au sens habituel du terme qu'une méthode d'organisation du travail de conception. Les principes XP ne peuvent que séduire quiconque a une expérience de la programmation et du développement, parce qu'ils constituent des solutions rationnelles aux problèmes bien connus de cette activité, et parce qu'ils formulent implicitement une critique radicale des méthodes punitives et improductives du passé.

On peut craindre que la mise en pratique des principes XP, qui supposent abnégation (« programmation sans ego ») et rigueur sans faille, ne se heurte à la sociologie réelle des populations concernées, notamment dans un pays latin comme la France où les signes extérieurs du pouvoir et du prestige ont souvent au moins autant d'importance que la satisfaction intériorisée du devoir accompli.

Une objection souvent formulée à l'encontre des principes XP, c'est qu'ils ne seraient adaptés qu'à des projets de petite taille. Mais justement, une des conclusions auxquelles la rédaction de ce livre nous a conduit, c'est que la grande taille de beaucoup de projets n'est pas vraiment justifiée par l'objectif poursuivi, et qu'il faut essayer de réduire la taille des projets dans toute la mesure du possible. C'est très souvent possible.



6  Le modèle du logiciel libre

Définition

Après avoir mobilisé les esprits et les langues, le mouvement du logiciel libre est devenu aujourd'hui (en 2004) un phénomène économique notable dont les acteurs sur la scène informatique ne peuvent plus ignorer l'existence. Rappelons-en brièvement les principes.

La locution « logiciel libre » désigne les logiciels produits sous une licence dite libre parce qu'elle garantit à tous et à chacun quatre libertés caractéristiques : Le dispositif établi par cette règle des quatre libertés est bien plus fort que la simple gratuité de logiciels tels que les freewares : il fait du logiciel ainsi déclaré libre un bien public.

D'un point de vue économique, le logiciel présente en effet des traits d'un bien public et des traits d'un bien privé : L'alternative se situe entre le logiciel comme bien privé, idée des entreprises commerciales, et le logiciel comme bien public, idée du logiciel libre.

Il découle de ces principes que le statut du code source détermine la nature publique du bien. La publicité du code interdit l'appropriation privée.

Outre le modèle économique exposé ci-dessus, le logiciel libre est aussi un mouvement associatif créé en 1984 par Richard M. Stallman sous le nom de Free Software Foundation (FSF). Stallman, informaticien au MIT et auteur depuis 1975 d'un logiciel extraordinaire, Emacs, a aussi créé en 1983 le projet GNU (« GNU is Not Unix ») destiné à créer un système d'exploitation libre de droits et dont le texte source serait librement et irrévocablement disponible à tout un chacun pour l'utiliser ou le modifier.

La principale licence libre (mais ce n'est pas la seule) est la GNU GPL (GNU General Public License), qui impose ses mêmes termes à tout logiciel dérivé d'un logiciel sous licence GPL.

Le logiciel libre n'est pas un paradoxe

Le comportement de ceux qui achètent même cher des choses disponibles gratuitement n'est pas forcément aussi aberrant qu'il semble au premier abord : récupérer un logiciel sur le réseau, l'installer, le mettre en oeuvre, suivre la sortie des nouvelles versions, s'assurer de son fonctionnement correct et régulier, fournir de l'assistance technique aux utilisateurs demande un travail non négligeable, et payer des gens pour le faire à votre place est un choix qui peut être raisonnable.

Le développement d'un logiciel consistant demande plusieurs années. S'il faut n mois pour écrire un programme destiné à traiter un problème pour mon usage personnel, l'adapter à une utilisation plus générale par des gens que je ne connais pas nécessite des modifications et l'écriture d'une documentation dont on estime en général l'ordre de grandeur du coût à 10n mois. Si maintenant je veux vendre ce logiciel dans les grandes surfaces, ce qui va coûter le plus cher c'est le marketing, la publicité, la constitution du réseau de distribution, l'emballage et la logistique, répondre au téléphone aux clients insatisfaits. Cela coûte (pour commencer) 100n mois de travail. Bref le travail de conception initial représente 1% du travail total, le travail technique au sens large 10%. Clairement ce n'est pas là que va porter l'effort principal de l'éditeur commercial.

Incidemment une conséquence de cet état de faits (dont ceux qui n'ont jamais écrit de logiciel ont peu conscience) est que la commercialisation d'un logiciel ne présente d'intérêt que si le marché espéré est considérable soit par le nombre d'unités vendues (cas de Microsoft Word) soit par le prix astronomique (cas de certains logiciels de modélisation moléculaire). Sinon il vaut mieux soit le diffuser comme logiciel libre, soit en céder les droits commerciaux à une entreprise dont c'est le métier, ou les deux puisque ce n'est pas incompatible. Ces faits élucident aussi le paradoxe apparent de l'existence simultanée de versions libres et commerciales du même logiciel : l'objet technique n'est pas la partie la plus coûteuse du logiciel vénal.

Le développement du logiciel libre

Le modèle du logiciel libre n'est pas sans influence sur la nature même du logiciel produit. En effet, dans ce contexte, un auteur peut facilement utiliser d'autres logiciels s'ils sont libres, que ce soit pour les utiliser directement tels quels au sein de son propre programme, pour recourir à des bibliothèques de fonctions générales ou pour s'inspirer d'un logiciel aux fonctions analogues mais dans un environnement différent.

Des systèmes de développement coopératif se mettent en place par le réseau, qui seraient impensables pour du logiciel non libre : les programmes sous forme source sont accessibles sur un site public, et chacun peut soumettre sa contribution. L'archétype de ce mode de développement est celui du noyau Linux proprement dit, coordonné par Linus Torvalds personnellement ; ce travail mobilise, pour 3 800 000 lignes de code, plus de 300 développeurs qui se connaissent souvent uniquement par courrier électronique, bien que des réunions plénières soient organisées une fois par an.

Pour qu'un tel procédé donne des résultats utilisables, il faut que le logiciel présente une architecture qui s'y prête, notamment une grande modularité, afin que chaque contributeur puisse travailler relativement indépendamment sur telle ou telle partie.

Finalement, la réutilisation de composants logiciels, dont plusieurs industriels parlent beaucoup depuis des années sans grand résultat, sera sans doute réalisée plutôt par les adeptes de l'Open Source. En effet, l'achat d'un composant logiciel est un investissement problématique, tandis que le récupérer sur le réseau, l'essayer, le jeter s'il ne convient pas, l'adopter s'il semble prometteur, c'est la démarche quotidienne du développeur libre. On pourra lire à ce sujet l'article de Josh Lerner et Jean Tirole, The Simple Economics of Open Source [68].

Dans le monde du libre le logiciel commence à prendre forme autour d'un noyau, noyau de code et noyau humain, généralement une seule personne ou un tout petit groupe. L'impulsion initiale procède le plus souvent du désir personnel des auteurs de disposer du logiciel en question, soit qu'il n'existe pas, soit que les logiciels existants ne leur conviennent pas, que ce soit à cause de leur prix ou de leur environnement d'exécution. Puis d'autres contributions viennent s'ajouter, presque par accrétion. Un coordonnateur émerge, souvent l'auteur initial : il assure la cohérence de l'ensemble. Quand des divergences de vues surgissent, il peut y avoir une scission (forking).

Les outils de travail des développeurs du libre sont (outre les outils de développement proprement dit tels qu'éditeurs de texte, compilateurs et débogueurs) le courrier électronique, des serveurs WWW pour abriter les sites d'archivage du logiciel tels que http://sourceforge.net/ ou http://freshmeat.net/ et des outils de gestion de version tels que CVS (Concurrent Versions System) destinés, comme le nom l'indique, à permettre le développement en réseau et à plusieurs d'un logiciel commun.

Le logiciel libre a pris son propre style, qui n'est pas sans points communs avec les principes énoncés ci-dessus de l'eXtreme Programming : pas de représentation graphique (cela passe mal par courrier électronique), pas de commentaires, la simplicité de l'implémentation est considérée comme plus importante que celle de l'interface. On consultera avec intérêt à ce propos les GNU Coding Standard[98], qui associent d'excellents conseils de programmation à de moins bons et à des injonctions morales et idéologiques parfois surprenantes. La lecture de ce document montre combien le monde du logiciel libre est imprégné des idées et des pratiques de la réutilisation de composants ou de logiciels déjà disponibles. Si on compare ces pratiques à celles du monde non libre, comme par exemple les EJB[102] (Enterprise JavaBeans), destinés eux aussi à la réutilisation, on est frappé du contraste entre l'efficacité rustique des méthodes « libres » et la complexité qui se dégage des 646 pages de spécifications des EJB[32].

Un article[39] de Richard Gabriel résume assez bien la vision générale qui est à la base des méthodes et pratiques de conception des développeurs du logiciel libre par quatre principes énoncés dans leur ordre de préséance : Ce qui est important dans ces principes, c'est bien sûr la hiérarchie entre eux, et surtout la prééminence de la simplicité à laquelle même la justesse peut être sacrifiée. En d'autres termes, il est prescrit de ne pas doubler la taille et la complexité d'un logiciel pour qu'il comporte la solution parfaite d'un cas de figure à l'occurrence exceptionnelle. Il est clair qu'un système d'exploitation comme VMS (des ordinateurs VAX de Digital Equipment) ou un langage de programmation comme Ada sont devenus obèses pour avoir voulu implanter des solutions parfaites à des problèmes qui n'intéressaient pas grand monde, et ont ainsi perdu des qualités de simplicité et de sobriété qui auraient plu à tout le monde. La lourdeur et la complexité de ces logiciels les ont rendus trop chers, trop encombrants, trop lents, trop difficiles à comprendre. À l'inverse, les versions initiales d'Unix et de C, qui n'étaient pas des logiciels libres mais qui en ont formé la matrice, implantaient des solutions d'une simplicité déconcertante, souvent au prix d'une certaine insuffisance conceptuelle, mais rétrospectivement il est patent que cette approche a donné de meilleurs résultats.

Comme Richard Gabriel le souligne, le langage C a été conçu pour faciliter l'écriture de son compilateur (le programme qui traduit en langage machine les programmes écrits par les utilisateurs), et c'est au programmeur de se plier à une syntaxe franchement atroce pour écrire du code acceptable par ce compilateur. L'application de la règle de simplicité maximum se fait donc aux dépens de toutes les qualités de clarté, de lisibilité et d'intelligibilité prônées jadis par les adeptes de la programmation structurée, mais en contrepartie le langage C (et le système Unix pour l'écriture duquel il a été inventé) ont gagné une versatilité et une souplesse de mise en oeuvre qui leur ont assuré le succès que l'on sait.

À la fin de son article Richard Gabriel énumère comme un repoussoir la recette du « grand système complexe » : pour commencer définir les spécifications de la « chose correcte » ; puis définir son implémentation ; enfin l'implémenter. Comme c'est la « chose correcte », 100% ou presque des caractéristiques requises sont là, mais comme la simplicité d'implémentation n'a jamais été une priorité, c'est long à implémenter. C'est grand et complexe ; pour l'utiliser il faut des plate-formes et des outils gros et chers.

Vous ne pouvez utiliser le « grand système complexe » que si votre employeur est riche : si son auteur a voulu créer un logiciel pour utilisateur final, c'est peut-être un choix commercial judicieux mais, si c'est un outil de développement, l'inconvénient est exponentiel, parce que de nos jours le développeur est souvent quelqu'un qui aime travailler la nuit chez lui, quand ce n'est pas un étudiant, alors si votre système de développement est cher et ne fonctionne que sur des plate-formes chères, il n'y aura pas beaucoup de logiciel développé avec lui. C'est ce qui est arrivé par exemple au langage Ada, malgré ses qualités éminentes : pendant longtemps ce fut un langage de riches, parce que sa conception procédait d'un appel d'offres du DoD, et que les clients étaient les contractants du DoD et du secteur aérospatial, à la réputation méritée de prospérité ; mais de ce fait le monde universitaire était laissé au bord de la route, ce qui se révéla une erreur fatale pour la dissémination du langage. Depuis quelques années un excellent environnement de développement libre est disponible (GNAT), mais pour permettre la popularité du langage c'est peut-être trop tard.

Toujours dans le domaine des outils de développement, on peut observer un contre-exemple au cas Ada : c'est le succès du système Eclipse, logiciel libre créé par IBM pour le développement de programmes Java. Cette publication sous licence libre a conféré à Eclipse un succès rapide, a tel point qu'il a assez vite supplanté les systèmes commerciaux. Une autre qualité d'Eclipse réside en ceci qu'il est facile de lui ajouter des extensions ou des adaptations par de petits programmes externes (plugins) : ont ainsi vu le jour des adaptations à d'autres langages, ainsi qu'à des méthodes particulières, comme eXtreme Programming. Cet exemple vient à l'appui de l'idée que les outils de développement ou d'infrastructure ont tout intérêt à être libres, même si leur créateur semble au départ perdre des bénéfices, parce que ces outils permettront la création ultérieure de plus de logiciels dans des conditions économiques plus avantageuses. On conçoit que Microsoft hésite à renoncer aux 70% de marge d'exploitation de Windows, mais peut-être les rattraperait-il facilement avec une version d'Office pour Linux...

Le logiciel libre n'est peut-être pas la panacée de tous les problèmes informatiques, mais il a pris une place désormais importante dans le monde du logiciel en général, il ne disparaîtra pas demain, et il convient donc de s'intéresser à ses méthodes, aussi originales que son modèle économique.



1
SADT est une marque déposée SOFTECH, et IGL Technology en France.
2
Il n'y a qu'en France --- et dans quelques pays qui partagent son sous-développement informatique --- que l'on considère comme normale la situation d'analphabétisme informatique profond qui affecte les gestionnaires et dirigeants d'entreprise. On pourra consulter un texte déjà cité de Michel Volle[117], qui semble ouvrir la possibilité d'étendre ce diagnostic à d'autres domaines techniques qui concernent l'entreprise.
3
Les diagrammes sont devenus treize depuis UML 2.0 paru en 2002, mais nous en resterons à la version 1 ; la version 2.0 est une tentative pour englober le monde du temps réel, mais à mon avis cela ne fait qu'introduire de la confusion dans un système déjà complexe. Le diagramme de collaboration a été rebaptisé « de communication » et les diagrammes supplémentaires sont :
4
Dans l'appellation « maîtrise d'ouvrage déléguée », c'est le client qui délègue, et pour bien faire il importe que cette MOAD fasse partie de son organisation.
© copyright Éditions Vuibert & Laurent Bloch 2004, 2005
Page d'accueil de ce livre
Précédent Remonter Suivant