Le billet précédent positionnait Agile comme le concurrent, initialement peu crédible, du "produit dominant" qu'est le Génie Logiciel. Mais nous l'avons vu, le challenger augmente progressivement ses parts de marché en diversifiant sa cible, et ce faisant il rattrape peu à peu son retard y compris sur les critères qui assurent au produit dominant sa position de force.
Pour autant, en matière d'innovation la victoire n'est jamais acquise d'avance. Bien des avancées prometteuses ont échoué, pour des raisons qui n'ont pas forcément à voir avec la qualité des technologies sous-jacentes, mais faute d'avoir habilement négocié cette montée en puissance.
Premier défi: enterrer la certification
Ainsi l'obession persistante de la communauté pour le sujet de la certification continue-t-elle de mener bataille sur un terrain, le contrôle des qualifications, où elle représente précisément ce qu'il ne faut pas faire, une concurrence frontale au modèle dominant. Le mouvement Agile doit trouver des solutions à cette question lancinante, mais des solutions qui soient compatibles avec sa propre philosophie.
Deuxième défi: proposer un modèle contractuel propre
De même, il faut répondre enfin à une autre question lancinante, celle du modèle contractuel. Nous continuons à dire que le contrat forfaitaire est un frein à l'adoption des pratiques Agiles en France, mais quelle solution proposons-nous?
Troisième défi: le choc des photos plutôt que le poids des mots
La prolifération de jargon rend difficile la conversation au-delà du cercle des initiés; la communication sur les pratiques Agile est brouillonne et trop centrée sur les étiquettes: Scrum vs Kanban vs Lean vs XP. J'applaudis ceux qui présentent la réalité du terrain, les éléments concrets et visibles qui au sein d'une équipe permettent d'identifier les pratiques Agiles et les bénéfices qu'elles apportent.
Quatrième défi: des chiffres!
A ce sujet, il est regrettable que l'une des critiques les plus courantes du mouvement Agile soit désormais la suivante: "Depuis 10 ans, il n'y a toujours pas de chiffres probants". La communauté Agile a désormais suffisamment d'ampleur pour être en principe capable de fournir ces chiffres.
Certes, il y a dix ans, la demande "montrez-nous vos statistiques" pouvait à raison être rejetée comme un discours de délégitimation, une façon de remettre à leur place ces "hippies du logiciel". Mais nous ne sommes plus en 2001, nous sommes en 2010; les éléments empiriques sont nécessaires, non seulement pour étayer ce que nous avançons, mais aussi pour faire le tri entre celles des pratiques qu'il faut conserver et celles qu'il faut modifier ou éliminer de notre discours. Non seulement nécessaires, mais disponibles, pour peu que nous nous donnions la peine d'aller les chercher.
Cinquième défi: le gouffre recherche-industrie
Dans cette logique, il est critique que la communauté Agile se rapproche de la communauté de la recherche et de l'enseignement. Pour l'instant, rares sont les chercheurs qui s'intéressent à l'Agilité, tout simplement parce que les travaux dans ce domaine ne trouveraient pas à être publiés. Ceci pourrait être réparé en entamant une démarche explicite pour faire de ce sujet une discipline soeur, voire concurrente, du Génie Logiciel. Après tout, cette dernière a pu persister pendant 40 ans sans solutionner les difficultés qui ont motivé sa création... il est temps qu'elle subisse la concurrence.
Cette liste n'est sans doute pas exhaustive mais suffirait probablement à tracer une feuille de route pour les approches Agiles au cours des 10 ans à venir.
Affichage des articles dont le libellé est rupture. Afficher tous les articles
Affichage des articles dont le libellé est rupture. Afficher tous les articles
Agile, une innovation de rupture
En quoi le débat en cours entre le Génie Logiciel inspiré par les conférences de 68-69 d'une part, et le challenger Agile d'autre part, répond-il à la théorie de la rupture évoquée dans le précédent billet?
Pour obtenir une réponse, il faut se repencher sur les origines du Génie Logiciel dans la "crise du logiciel". Celle-ci se manifeste initialement par des difficultés à fournir des prévisions fiables quant aux projets, souvent liées à des allers-retours autour des exigences. Le critère de performance exigé de tout ce qui se présente comme une solution à ladite crise est, en un mot, la possibilité de contrôler tout aléa. On va privilégier la traçabilité, la documentation, et le respect des contraintes que ces outils permettent de suivre le mieux: délais (et donc coûts) maîtrisés, spécifications respectées.
"Ça ne peut pas marcher"
Cette phrase qui constitue le leitmotiv d'un des chapitres du livre de Kent Beck illustre bien en quoi l'approche Agile joue le rôle du produit "gadget", totalement insuffisant, dans l'analogie avec la photo numérique autour des années 1990.
Planifier en permanence, ça ne peut pas marcher, on ferait peur au client (pas assez de contrôle). Mettre une nouvelle version en exploitation tous les mois ou deux, ça ne peut pas marcher, on ferait peur aux utilisateurs (pas assez de contrôle). Démarrer le développement avec une vision architecturale résumée en une métaphore, ça ne peut pas marcher, et si on s'était trompés? (Pas assez de contrôle.) Ne pas anticiper sur les besoins futurs lors de la conception, ça ne peut pas marcher, on se retrouvera coincés (pas assez de contrôle). Faire écrire les tests par les programmeurs, ça ne peut pas marcher, tout le monde sait que les programmeurs ne peuvent pas tester leur propre travail et que le test est une profession à part entière (pas assez de spécialisation, donc de contrôle). Travailler en binômes, ça ne peut pas marcher, ça va prendre deux fois plus longtemps, et ils risquent de ne pas s'entendre (pas assez de contrôle, mais aussi une vision du développement comme activité mécanique, réduite à la saisie de code au clavier).
Pour la plupart ces arguments sont légitimes, de même qu'il est légitime de condamner en 1990 la nouvelle technologie numérique comme tout à fait inadéquate.
Valeurs classiques contre valeurs agiles
L'approche Agile quand à elle est initialement destinée à des projets qui ne se soucient que très peu de contrôler et de tracer. On privilégie la communication directe et orale avec le client, lui permettant d'ajuster sa demande en temps réel; la qualité du produit et sa pertinence pour répondre aux besoins réels (plus qu'à ceux exprimés), la maîtrise des priorités fonctionnelles sous contrainte de délais.
Ne pas chercher à faire concurrence aux "méthodologies" dominantes et aux approches de management orientées sur les production documentaires de ces dernières permet aux "agilistes" comme on ne les appellera que plus tard de s'affranchir de nombreuses contraintes, et d'inventer un mode de développement très souple, basé sur des itérations courtes régies par la règle du "timebox" (on cherche à en faire le maximum en temps imparti plutôt qu'à terminer un objectif fixe quitte à jouer les prolongations), décomposé par incréments fonctionnels. Les phases amont et le travail documentaire sont réduits à l'essentiel, c'est-à-dire à ce qui permet à l'équipe de partager une même compréhension de l'objectif. Le chef de projet perd ses prérogatives: il n'attribue plus les tâches et ne joue plus les intermédiaires, le client étant présent sur place. Des dispositifs techniques (automatisation des tests, intégration continue) limitent au minimum les coûts d'intégration et de refonte.
Une métaphore souvent employée compare l'équipe Agile à des musiciens de jazz qui improvisent, par rapport à leurs collègues dans une formation classique: l'absence de contrôle n'implique pas moins de technicité, et de satisfaction procurée par le résultat final.
Une recherche textuelle dans les actes des conférences de l'OTAN (NATO1968), comparée à la même recherche (grâce à Google Books) dans les actes de la conférence européenne sur XP et les processus agiles (XP2008) permet d'objectiver quelque peu ces différences de valeurs:
Agile, dix ans après
Mais depuis 2001, les pratiques ont évolué: le challenger Agile a progressé sur plusieurs critères de performance y compris ceux reconnus par le modèle dominant. C'est exactement ce que prédit la théorie de la rupture, pourtant cette évolution est en grande partie invisible, très peu reconnue par les professionnels qui ont rejoint la communauté récemment et ignorée même d'un certain nombre de vétérans. (Ou bien, elle se traduit pour certains par un inconfort, un sentiment que "Agile c'est devenu n'importe quoi".)
Plusieurs pratiques considérées désormais comme au coeur de Scrum sont ainsi apparues depuis 2001, postérieurement au terme “Agile” lui-même: par exemple les Rétrospectives et le Task Board, deux pratiques très proche du "noyau" mais pourtant d'importation relativement récente. Quant à Extreme Programming son statut de "work in progress" est acquis depuis la deuxième édition du livre de Kent Beck.
Des pratiques sont apparues pour combler par exemple des lacunes dans la prise en compte de l'ergonomie par les approches Agiles, ou encore pour donner des directives plus précises sur la façon d'organiser les "phases amont", le recueil des exigences: on parle de Personas, de Charte Projet, de Story Mapping.
Initialement vécue comme une obligation déraisonnable, la pratique Extreme Programming désignée à l'origine par le conseil "faites écrire vos tests de recette par le client" a beaucoup évolué et donné naissance à des écoles et appellations diverses: ATDD ou pilotage par les tests client, BDD ou Spécifications Exécutables. Bien que ce sujet soit actuellement en pleine fermentation pour ainsi dire, une tendance se dégage clairement: ces évolutions commencent à répondre de façon satisfaisante aux exigences de formalisation et de traçabilité qui sont l'apanage des organisations les plus exigeantes en termes de contrôle.
Des pans entiers de pratiques ont enfin servi à occuper de nouveaux terrains. En 2001, Scrum et XP se focalisent sur de petites équipes colocalisées dont la préoccupation presque exclusive est le développement dans un contexte projet: la "date de fin" est une des préoccupations majeures, on conçoit le projet comme un effort unique au-delà duquel l'équipe passe à autre chose.
Ce n'est qu'au fil du temps que la recherche d'adaptation des approches agiles à d'autres contextes conduit à explorer des pratiques alternatives. Ainsi l'approche Lean et Kanban peut-elle trouver un terrain d'application fertile parmi les équipes chargées de maintenance ou de TMA. La communauté Agile voit aussi se développer des mouvements visant à repenser d'autres métiers, à l'image de DevOps qui réunit des admin systèmes sensibles aux évolutions du développement.
Agile dans dix ans?
En 2010, la photo numérique a entièrement remplacé la technologie précédente (et une nouvelle mutation s'amorce, celle du cinéma, mais c'est une autre histoire). Peut-on imaginer un avenir comparable pour les approches Agiles?
Il convient de rester prudent. D'une part, on apprend vite quand on s'intéresse à l'histoire et à la sociologie des sciences et des techniques que le progrès n'est jamais gagné d'avance. (J'y reviendrai, notamment en parlant des travaux de Bruno Latour qui sont très pertinents pour comprendre ce qui se trame autour de l'Agilité.) Rejeté par toute la communauté médicale de son temps, Semmelweiss ne fut reconnu comme un pionnier de l'hygiène médicale qu'après avoir été poussé à une dépression nerveuse qui lui fut fatale. Il faut du temps, beaucoup de travail et sans doute un peu de chance pour qu'une idée s'impose de manière irréversible; le plus simple est sans doute encore de considérer que tout est réversible.
Une existe une autre raison d'être prudent: le statut de "challenger" ne confère pas automatiquement l'infallibilité de ceux qui se rangent sous sa bannière. Comme le disait Carl Sagan: "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." On s'est moqués de Christophe Colomb, de Robert Fulton - l'inventeur du bateau à vapeur - des frères Wright, et de Semmelweiss.
Mais on s'est aussi moqués de tout un tas de gugusses que l'histoire a eu bien raison d'ignorer.
Notamment, certaines lacunes persistantes continuent à plomber la communauté Agile, et risquent de mettre en péril l'avenir du sujet. Je traiterai ce sujet brièvement dans le prochain billet.
Pour obtenir une réponse, il faut se repencher sur les origines du Génie Logiciel dans la "crise du logiciel". Celle-ci se manifeste initialement par des difficultés à fournir des prévisions fiables quant aux projets, souvent liées à des allers-retours autour des exigences. Le critère de performance exigé de tout ce qui se présente comme une solution à ladite crise est, en un mot, la possibilité de contrôler tout aléa. On va privilégier la traçabilité, la documentation, et le respect des contraintes que ces outils permettent de suivre le mieux: délais (et donc coûts) maîtrisés, spécifications respectées.
"Ça ne peut pas marcher"
Cette phrase qui constitue le leitmotiv d'un des chapitres du livre de Kent Beck illustre bien en quoi l'approche Agile joue le rôle du produit "gadget", totalement insuffisant, dans l'analogie avec la photo numérique autour des années 1990.
Planifier en permanence, ça ne peut pas marcher, on ferait peur au client (pas assez de contrôle). Mettre une nouvelle version en exploitation tous les mois ou deux, ça ne peut pas marcher, on ferait peur aux utilisateurs (pas assez de contrôle). Démarrer le développement avec une vision architecturale résumée en une métaphore, ça ne peut pas marcher, et si on s'était trompés? (Pas assez de contrôle.) Ne pas anticiper sur les besoins futurs lors de la conception, ça ne peut pas marcher, on se retrouvera coincés (pas assez de contrôle). Faire écrire les tests par les programmeurs, ça ne peut pas marcher, tout le monde sait que les programmeurs ne peuvent pas tester leur propre travail et que le test est une profession à part entière (pas assez de spécialisation, donc de contrôle). Travailler en binômes, ça ne peut pas marcher, ça va prendre deux fois plus longtemps, et ils risquent de ne pas s'entendre (pas assez de contrôle, mais aussi une vision du développement comme activité mécanique, réduite à la saisie de code au clavier).
Pour la plupart ces arguments sont légitimes, de même qu'il est légitime de condamner en 1990 la nouvelle technologie numérique comme tout à fait inadéquate.
Valeurs classiques contre valeurs agiles
L'approche Agile quand à elle est initialement destinée à des projets qui ne se soucient que très peu de contrôler et de tracer. On privilégie la communication directe et orale avec le client, lui permettant d'ajuster sa demande en temps réel; la qualité du produit et sa pertinence pour répondre aux besoins réels (plus qu'à ceux exprimés), la maîtrise des priorités fonctionnelles sous contrainte de délais.
Ne pas chercher à faire concurrence aux "méthodologies" dominantes et aux approches de management orientées sur les production documentaires de ces dernières permet aux "agilistes" comme on ne les appellera que plus tard de s'affranchir de nombreuses contraintes, et d'inventer un mode de développement très souple, basé sur des itérations courtes régies par la règle du "timebox" (on cherche à en faire le maximum en temps imparti plutôt qu'à terminer un objectif fixe quitte à jouer les prolongations), décomposé par incréments fonctionnels. Les phases amont et le travail documentaire sont réduits à l'essentiel, c'est-à-dire à ce qui permet à l'équipe de partager une même compréhension de l'objectif. Le chef de projet perd ses prérogatives: il n'attribue plus les tâches et ne joue plus les intermédiaires, le client étant présent sur place. Des dispositifs techniques (automatisation des tests, intégration continue) limitent au minimum les coûts d'intégration et de refonte.
Une métaphore souvent employée compare l'équipe Agile à des musiciens de jazz qui improvisent, par rapport à leurs collègues dans une formation classique: l'absence de contrôle n'implique pas moins de technicité, et de satisfaction procurée par le résultat final.
Une recherche textuelle dans les actes des conférences de l'OTAN (NATO1968), comparée à la même recherche (grâce à Google Books) dans les actes de la conférence européenne sur XP et les processus agiles (XP2008) permet d'objectiver quelque peu ces différences de valeurs:
- le mot-clé "control" apparaît plus de 100 fois dans NATO1968, 27 fois dans XP2008 (et souvent dans le contexte "groupe contrôle vs groupe expérimental", pour les papiers scientifiques
- le mot-clé "team" apparaît plus de 100 fois dans XP2008, seulement 17 fois dans NATO1968
- le mot-clé "skill" apparaît seulement 5 fois dans NATO1968, 15 fois dans XP2008
- le mot-clé "motivation" apparaît seulement une fois dans NATO1968 ("la motivation de cette conférence..."), 12 fois dans XP2008 et pour la plupart au sens "motivation de l'équipe"
Agile, dix ans après
Mais depuis 2001, les pratiques ont évolué: le challenger Agile a progressé sur plusieurs critères de performance y compris ceux reconnus par le modèle dominant. C'est exactement ce que prédit la théorie de la rupture, pourtant cette évolution est en grande partie invisible, très peu reconnue par les professionnels qui ont rejoint la communauté récemment et ignorée même d'un certain nombre de vétérans. (Ou bien, elle se traduit pour certains par un inconfort, un sentiment que "Agile c'est devenu n'importe quoi".)
Plusieurs pratiques considérées désormais comme au coeur de Scrum sont ainsi apparues depuis 2001, postérieurement au terme “Agile” lui-même: par exemple les Rétrospectives et le Task Board, deux pratiques très proche du "noyau" mais pourtant d'importation relativement récente. Quant à Extreme Programming son statut de "work in progress" est acquis depuis la deuxième édition du livre de Kent Beck.
Des pratiques sont apparues pour combler par exemple des lacunes dans la prise en compte de l'ergonomie par les approches Agiles, ou encore pour donner des directives plus précises sur la façon d'organiser les "phases amont", le recueil des exigences: on parle de Personas, de Charte Projet, de Story Mapping.
Initialement vécue comme une obligation déraisonnable, la pratique Extreme Programming désignée à l'origine par le conseil "faites écrire vos tests de recette par le client" a beaucoup évolué et donné naissance à des écoles et appellations diverses: ATDD ou pilotage par les tests client, BDD ou Spécifications Exécutables. Bien que ce sujet soit actuellement en pleine fermentation pour ainsi dire, une tendance se dégage clairement: ces évolutions commencent à répondre de façon satisfaisante aux exigences de formalisation et de traçabilité qui sont l'apanage des organisations les plus exigeantes en termes de contrôle.
Des pans entiers de pratiques ont enfin servi à occuper de nouveaux terrains. En 2001, Scrum et XP se focalisent sur de petites équipes colocalisées dont la préoccupation presque exclusive est le développement dans un contexte projet: la "date de fin" est une des préoccupations majeures, on conçoit le projet comme un effort unique au-delà duquel l'équipe passe à autre chose.
Ce n'est qu'au fil du temps que la recherche d'adaptation des approches agiles à d'autres contextes conduit à explorer des pratiques alternatives. Ainsi l'approche Lean et Kanban peut-elle trouver un terrain d'application fertile parmi les équipes chargées de maintenance ou de TMA. La communauté Agile voit aussi se développer des mouvements visant à repenser d'autres métiers, à l'image de DevOps qui réunit des admin systèmes sensibles aux évolutions du développement.
Agile dans dix ans?
En 2010, la photo numérique a entièrement remplacé la technologie précédente (et une nouvelle mutation s'amorce, celle du cinéma, mais c'est une autre histoire). Peut-on imaginer un avenir comparable pour les approches Agiles?
Il convient de rester prudent. D'une part, on apprend vite quand on s'intéresse à l'histoire et à la sociologie des sciences et des techniques que le progrès n'est jamais gagné d'avance. (J'y reviendrai, notamment en parlant des travaux de Bruno Latour qui sont très pertinents pour comprendre ce qui se trame autour de l'Agilité.) Rejeté par toute la communauté médicale de son temps, Semmelweiss ne fut reconnu comme un pionnier de l'hygiène médicale qu'après avoir été poussé à une dépression nerveuse qui lui fut fatale. Il faut du temps, beaucoup de travail et sans doute un peu de chance pour qu'une idée s'impose de manière irréversible; le plus simple est sans doute encore de considérer que tout est réversible.
Une existe une autre raison d'être prudent: le statut de "challenger" ne confère pas automatiquement l'infallibilité de ceux qui se rangent sous sa bannière. Comme le disait Carl Sagan: "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." On s'est moqués de Christophe Colomb, de Robert Fulton - l'inventeur du bateau à vapeur - des frères Wright, et de Semmelweiss.
Mais on s'est aussi moqués de tout un tas de gugusses que l'histoire a eu bien raison d'ignorer.
Notamment, certaines lacunes persistantes continuent à plomber la communauté Agile, et risquent de mettre en péril l'avenir du sujet. Je traiterai ce sujet brièvement dans le prochain billet.
Théorie de la rupture
La théorie de la rupture est due à Clayton Christensen qui la présente en 1997 dans The Innovator's Dilemma. Le sous-titre, éloquent, avertit du risque que présentent certaines innovations ou "ruptures technologiques": "lorsque de nouvelles technologies entraînent la chute de grandes entreprises".
Christensen distingue deux types d'innovation, l'innovation de continuité et l'innovation de rupture. La première est caractérisée par des produits qui renforcent, dans le contexte concurrentiel, la position dominante des acteurs déjà bien placés sur ce marché: ces produits sont jugés sur des critères de performance déjà reconnus. Imaginez par exemple la dernière génération des appareils photos numériques, qui passent de 8 à 12 megapixels. (Une innovation "révolutionnaire" n'est pas nécessairement une rupture en ce sens, ainsi l'article Wikipedia consacré à la théorie précise que l'automobile fut une révolution mais pas, dans ses effets sur les acteurs de l'économie industrielle, une véritable rupture.)
L'innovation de rupture se caractérise par l'ouverture de nouveaux marchés, et la mise en danger des acteurs dominants dans un marché donné; elle propose quelque chose d'inattendu en décalage avec les critères de valorisation dominants.
L'histoire de la photo numérique à ses débuts est à ce titre éclairante, sa victime emblématique étant Polaroid, l'un de ces noms de marque passés dans l'usage courant, tant son emprise sur un important segment du marché était complète. Pourtant, en 2001 Polaroid se mettait en faillite, pour ne renaître de ses cendres qu'à la suite du rachat de la marque et presque uniquement de cela par des investisseurs cherchant à profiter d'une image encore favorable.
Pourtant, seulement dix ans plus tôt, bien malin qui aurait pu prédire à la photographie le bel avenir qui est devenu notre présent: disparition inéluctable non seulement des modèles argentiques mais également de tout un secteur d'économie qui en dépendait, comme les petites boutiques qui assuraient le développement de nos "péloches".
Ainsi en 1991 le modèle Fotoman, est selon une critique pourtant lucide "incapable de produire des images de qualité professionnelle". En noir et blanc et d'une résolution maximum de 320x240, il coûte la bagatelle de 1000$. Ce n'est en fait qu'un gadget, conseillé aux personnes qui souhaitent s'amuser sur leur PC à triturer et retoucher leurs photos.
Comment un tel produit arrive-t-il, petit à petit, à s'imposer jusqu'à vingt ans plus tard avoir totalement détrôné la génération précédente? Pour avoir un début de réponse, il faut comprendre que les acteurs dominants du marché le sont en vertu de l'excellence de leurs produits selon des critères de performance appréciés par la clientèle: en l'occurrence, la finesse de l'image, le bon rendu des couleurs, etc. De ce point de vue la photo numérique présente des avantages (facilité de stockage, moins d'usure mécanique, manipulation numérique) mais ceux-ci ne sont pas suffisant pour l'emporter face aux concurrents dominants.
Oui, mais certains marchés n'ont que faire de ces critères de performance majeurs. Parmi les premiers clients auxquels s'adresse le numérique on trouve des fabricants d'avions, qui doivent prendre leurs appareils sous toutes les coutures pendant leur construction pour des raisons règlementaires, et vont donc faire des économies considérables sur le développement chimique, mais ne se soucient guère d'une résolution très fine. Ou bien encore des journalistes qui vont privilégier la transmission rapide d'une information brûlante mais ne sont que peu handicapés, compte tenu des qualités d'impression, par une résolution limitée ou par le noir et blanc.
L'innovation de rupture est donc portée par des produits initialement totalement inadéquats quand on les juge à l'aune des critères de performance établis, mais qui vont conquérir un marché de niche puis se développer. L'innovation plus classique, "de continuité", permet progressivement à ces produits de rattraper tout ou partie de leur retard sur ces critères dominants, et c'est ainsi qu'ils peuvent finir par mettre en danger les leaders du marché.
Alors, en quoi le débat entre "Génie Logiciel" et "Agile" peut-il être considéré comme une instantiation de ce modèle? Certes, il faut faire preuve d'un peu de prudence: considérer l'un et l'autre comme des "produits" en concurrence sur un "marché" relève, sinon de la métaphore, d'une moins d'une interprétation assez libre de ces termes. Je trouve pourtant que le modèle s'applique plutôt bien, et permet d'expliquer non seulement le succès initial de l'approche Agile mais également ses évolutions au cours des dernières années. (Evolutions qui sont souvent mal connues des personnes qui pratiquent ces approches et même de certains experts: toujours ce blocage sur l'histoire...)
L'idée est donc d'analyser le Génie Logiciel comme le produit dominant, et d'expliquer cette domination par le fait qu'il répond aux critères exigés par le marché. L'histoire du projet Chorus nous suggère que "le succès du projet" ne fait pas nécessairement partie de ces critères... alors quels sont-ils? Selon quel critère de performance le discours classique du Génie Logiciel, issu des conférences de 1968 et 1969, est-il, malgré ces échecs, jugé satisfaisant, à tel point qu'on enseigne encore le cycle en V dans les universités?
Je laisse la question en suspens jusqu'au prochain billet... A vous de réagir dans les commentaires.
Christensen distingue deux types d'innovation, l'innovation de continuité et l'innovation de rupture. La première est caractérisée par des produits qui renforcent, dans le contexte concurrentiel, la position dominante des acteurs déjà bien placés sur ce marché: ces produits sont jugés sur des critères de performance déjà reconnus. Imaginez par exemple la dernière génération des appareils photos numériques, qui passent de 8 à 12 megapixels. (Une innovation "révolutionnaire" n'est pas nécessairement une rupture en ce sens, ainsi l'article Wikipedia consacré à la théorie précise que l'automobile fut une révolution mais pas, dans ses effets sur les acteurs de l'économie industrielle, une véritable rupture.)
L'innovation de rupture se caractérise par l'ouverture de nouveaux marchés, et la mise en danger des acteurs dominants dans un marché donné; elle propose quelque chose d'inattendu en décalage avec les critères de valorisation dominants.
L'histoire de la photo numérique à ses débuts est à ce titre éclairante, sa victime emblématique étant Polaroid, l'un de ces noms de marque passés dans l'usage courant, tant son emprise sur un important segment du marché était complète. Pourtant, en 2001 Polaroid se mettait en faillite, pour ne renaître de ses cendres qu'à la suite du rachat de la marque et presque uniquement de cela par des investisseurs cherchant à profiter d'une image encore favorable.
Pourtant, seulement dix ans plus tôt, bien malin qui aurait pu prédire à la photographie le bel avenir qui est devenu notre présent: disparition inéluctable non seulement des modèles argentiques mais également de tout un secteur d'économie qui en dépendait, comme les petites boutiques qui assuraient le développement de nos "péloches".
Ainsi en 1991 le modèle Fotoman, est selon une critique pourtant lucide "incapable de produire des images de qualité professionnelle". En noir et blanc et d'une résolution maximum de 320x240, il coûte la bagatelle de 1000$. Ce n'est en fait qu'un gadget, conseillé aux personnes qui souhaitent s'amuser sur leur PC à triturer et retoucher leurs photos.
Comment un tel produit arrive-t-il, petit à petit, à s'imposer jusqu'à vingt ans plus tard avoir totalement détrôné la génération précédente? Pour avoir un début de réponse, il faut comprendre que les acteurs dominants du marché le sont en vertu de l'excellence de leurs produits selon des critères de performance appréciés par la clientèle: en l'occurrence, la finesse de l'image, le bon rendu des couleurs, etc. De ce point de vue la photo numérique présente des avantages (facilité de stockage, moins d'usure mécanique, manipulation numérique) mais ceux-ci ne sont pas suffisant pour l'emporter face aux concurrents dominants.
Oui, mais certains marchés n'ont que faire de ces critères de performance majeurs. Parmi les premiers clients auxquels s'adresse le numérique on trouve des fabricants d'avions, qui doivent prendre leurs appareils sous toutes les coutures pendant leur construction pour des raisons règlementaires, et vont donc faire des économies considérables sur le développement chimique, mais ne se soucient guère d'une résolution très fine. Ou bien encore des journalistes qui vont privilégier la transmission rapide d'une information brûlante mais ne sont que peu handicapés, compte tenu des qualités d'impression, par une résolution limitée ou par le noir et blanc.
L'innovation de rupture est donc portée par des produits initialement totalement inadéquats quand on les juge à l'aune des critères de performance établis, mais qui vont conquérir un marché de niche puis se développer. L'innovation plus classique, "de continuité", permet progressivement à ces produits de rattraper tout ou partie de leur retard sur ces critères dominants, et c'est ainsi qu'ils peuvent finir par mettre en danger les leaders du marché.
Alors, en quoi le débat entre "Génie Logiciel" et "Agile" peut-il être considéré comme une instantiation de ce modèle? Certes, il faut faire preuve d'un peu de prudence: considérer l'un et l'autre comme des "produits" en concurrence sur un "marché" relève, sinon de la métaphore, d'une moins d'une interprétation assez libre de ces termes. Je trouve pourtant que le modèle s'applique plutôt bien, et permet d'expliquer non seulement le succès initial de l'approche Agile mais également ses évolutions au cours des dernières années. (Evolutions qui sont souvent mal connues des personnes qui pratiquent ces approches et même de certains experts: toujours ce blocage sur l'histoire...)
L'idée est donc d'analyser le Génie Logiciel comme le produit dominant, et d'expliquer cette domination par le fait qu'il répond aux critères exigés par le marché. L'histoire du projet Chorus nous suggère que "le succès du projet" ne fait pas nécessairement partie de ces critères... alors quels sont-ils? Selon quel critère de performance le discours classique du Génie Logiciel, issu des conférences de 1968 et 1969, est-il, malgré ces échecs, jugé satisfaisant, à tel point qu'on enseigne encore le cycle en V dans les universités?
Je laisse la question en suspens jusqu'au prochain billet... A vous de réagir dans les commentaires.
Chorus, une histoire pas drôle
Lors de mes interventions (par exemple dernièrement pour Agile Tour Nancy) sur le sujet que j'ai abordé au fil des précédents billets, il y a toujours un moment ou je sais que j'arriverai à tirer un rire de toute la salle: je viens de rappeler la date de naissance du Génie Logiciel et le contexte de sa création, celui de la "crise du logiciel".
Il n'y a plus qu'à lancer un constat: "Heureusement, nous avons tous remarqué que la Crise du Logiciel est maintenant résolue." Effet garanti.
Quels étaient effet les symptômes de ladite Crise en 1968? Dépassement de délais, mauvaise qualité, inadaptation des logiciels aux besoins des utilisateurs...
Que peut-on observer en 2010? Qu'il existe encore des projets comme Chorus. Si vous n'en avez jamais entendu parler, je vous conseille de vous documenter: c'est de votre argent qu'il s'agit, puisque Chorus est le nouveau système d'information destiné à toutes les administrations françaises. Le projet prévu sur quatre ans démarre en Mars 2006, son coût annoncé aux parlementaires à l'origine est déjà important: 600M€.
Dès le début 2008 apparaissent les premières dérives et l'on apprend que des retards sont à envisager, que le budget serait dépassé. Fin 2008, une "mise au point" du ministère permet d'apprendre qu'en fait le budget communiqué ne tenait pas compte des coûts de fonctionnement, chiffrés à 100M€ annuels sur cinq ans: la facture serait donc de 1,1Md€. Un petit oubli, en somme. (Un rapport parlementaire de juillet 2010, un peu inquiétant, recommande "d'actualiser l'évaluation du coût complet de Chorus" - ce qui laisse supposer que ce coût réel est encore inconnu à l'heure actuelle...) Les délais s'accumulent, et dès 2009 Chorus qui devait être déployé entièrement à partir de 2010 se voit repoussé à janvier 2011, et ce malgré une révision à la baisse de ses objectifs fonctionnels.
Il y a pire: Chorus... ne fonctionne pas. Plus exactement son installation perturbe le paiement des factures aux fournisseurs des administrations. Alors que l'Etat gronde le secteur privé sur les délais de paiement, son propre système d'information met en difficulté de très nombreuses PME qui se retrouvent dans l'incapacité d'encaisser leur dû: un comble! Est-ce une difficulté transitoire? C'est en tout cas un transitoire qui dure... et la Cour des Comptes émet des réserves sur l'éventualité que Chorus puisse un jour assumer pleinement la comptabilité de l'Etat français.
Alors, oui, cela fait rire, de constater que quarante ans après, les méthodes proposées par le Génie Logiciel, loin d'avoir résolu la crise, semblent contribuer à la perpétuer: c'est évidemment un rire jaune.
Pourtant force est de constater que le Génie Logiciel se porte bien. On enseigne toujours le cycle en V dans les universités: voici un exemple, notez cependant qu'à l'heure où j'écris ces lignes il vous sera nécessaire de défiler plusieurs pages d'avertissements PHP avant de lire le descriptif de cette unité d'enseignement. (Tout un symbole...)
Comment comprendre cette situation dominante occupée par le Génie Logiciel? Et quelle grille de lecture nous permettrait de mieux appréhender le positionnement des approches Agiles dans ce débat? J'ai trouvé un certain nombre d'explications dans les thèses de Christensen, auteur de la Théorie de la Rupture. Ce sera le sujet du prochain billet.
Il n'y a plus qu'à lancer un constat: "Heureusement, nous avons tous remarqué que la Crise du Logiciel est maintenant résolue." Effet garanti.
Quels étaient effet les symptômes de ladite Crise en 1968? Dépassement de délais, mauvaise qualité, inadaptation des logiciels aux besoins des utilisateurs...
Que peut-on observer en 2010? Qu'il existe encore des projets comme Chorus. Si vous n'en avez jamais entendu parler, je vous conseille de vous documenter: c'est de votre argent qu'il s'agit, puisque Chorus est le nouveau système d'information destiné à toutes les administrations françaises. Le projet prévu sur quatre ans démarre en Mars 2006, son coût annoncé aux parlementaires à l'origine est déjà important: 600M€.
Dès le début 2008 apparaissent les premières dérives et l'on apprend que des retards sont à envisager, que le budget serait dépassé. Fin 2008, une "mise au point" du ministère permet d'apprendre qu'en fait le budget communiqué ne tenait pas compte des coûts de fonctionnement, chiffrés à 100M€ annuels sur cinq ans: la facture serait donc de 1,1Md€. Un petit oubli, en somme. (Un rapport parlementaire de juillet 2010, un peu inquiétant, recommande "d'actualiser l'évaluation du coût complet de Chorus" - ce qui laisse supposer que ce coût réel est encore inconnu à l'heure actuelle...) Les délais s'accumulent, et dès 2009 Chorus qui devait être déployé entièrement à partir de 2010 se voit repoussé à janvier 2011, et ce malgré une révision à la baisse de ses objectifs fonctionnels.
Il y a pire: Chorus... ne fonctionne pas. Plus exactement son installation perturbe le paiement des factures aux fournisseurs des administrations. Alors que l'Etat gronde le secteur privé sur les délais de paiement, son propre système d'information met en difficulté de très nombreuses PME qui se retrouvent dans l'incapacité d'encaisser leur dû: un comble! Est-ce une difficulté transitoire? C'est en tout cas un transitoire qui dure... et la Cour des Comptes émet des réserves sur l'éventualité que Chorus puisse un jour assumer pleinement la comptabilité de l'Etat français.
Alors, oui, cela fait rire, de constater que quarante ans après, les méthodes proposées par le Génie Logiciel, loin d'avoir résolu la crise, semblent contribuer à la perpétuer: c'est évidemment un rire jaune.
Pourtant force est de constater que le Génie Logiciel se porte bien. On enseigne toujours le cycle en V dans les universités: voici un exemple, notez cependant qu'à l'heure où j'écris ces lignes il vous sera nécessaire de défiler plusieurs pages d'avertissements PHP avant de lire le descriptif de cette unité d'enseignement. (Tout un symbole...)
Comment comprendre cette situation dominante occupée par le Génie Logiciel? Et quelle grille de lecture nous permettrait de mieux appréhender le positionnement des approches Agiles dans ce débat? J'ai trouvé un certain nombre d'explications dans les thèses de Christensen, auteur de la Théorie de la Rupture. Ce sera le sujet du prochain billet.
Quarante ans de crise
Connaissez-vous l'expression "crise du logiciel"? Peut-être connaissez-vous un peu mieux une de ses manifestations, la célèbre illustration du "Projet Balançoire". Tellement célèbre qu'elle a depuis quelque temps son propre site web 2.0, normalement elle se passe de commentaires...
Le terme "crise du logiciel" est contemporain d'une autre expression certainement plus familière, "Génie Logiciel", formulée en 1968 lors d'une conférence organisée sous les auspices de l'OTAN. La seconde fut proposée comme solution de la première.
La Crise se manifestait par divers aspects. Les projets de développement dépassaient les délais et budgets impartis, les logiciels produits étaient de mauvaise qualité et leurs performances insuffisantes, ils ne répondaient pas aux exigences exprimées, ils étaient difficiles à faire évoluer.
Il y eut non pas une mais deux conférences de l'OTAN sur le Génie Logiciel, à un an d'intervalle. Que se passa-t-il durant ces douze mois? Presque en filigrane du discours officiel, on devine un événement d'importance.
En 1968, la première conférence semble poser une question. "L'approche de l'ingénieur est-elle appropriée pour aborder le développement de logiciels?" Environ cinquante experts venus de onze pays sont présents. Parmi les participants on compte des sommités comme Edsger Dijkstra (connu pour sa campagne contre le "goto" et en faveur de la programmation structurée), Alan Perlis (créateur d'Algol et auteur de proverbes qui sont au logiciel ce qu'une certaine tradition japonaise est au jeu de Go) ou Peter Naur (co-crédité de l'invention de la notation BNF pour décrire les langages de programmation).
Les actes des deux conférences disponibles sur le Web, dans une version PDF d'une qualité remarquable alors que la plupart des documents de cette époque sont en général simplement scannés, donc non indexés ni "cherchables", méritent d'être lus avec attention; j'avoue ne les avoir que trop rapidement parcourus jusqu'à présent, en tout cas pas avec la minutie qu'un historien leur accorderait. On y trouve par exemple ce conseil de Peter Naur qui recommande de s'intéresser aux idées d'un jeune architecte, Christopher Alexander. Le même Alexander qui sera redécouvert vingt anx plus tard par un certain Kent Beck, donnant naissance au mouvement des Design Patterns. Structurés d'une façon très systématique, ils couvrent la quasi-totalité des préoccupations encore d'actualité aujourd'hui quant à la façon de mener des projets dans le domaine du logiciel.
Ces documents sont éloquents quant au degré de controverse que suscite la question du génie logiciel. Voici une citation d'un participant: "La chose la plus dangereuse dans le domaine du logiciel est l'idée, apparemment presque universelle, que vous allez spécifier ce qu'il y a à réaliser, puis le réaliser. Voilà d'où viennent la plupart de nos ennuis. On appelle réussis les projets qui sont conformes à leurs spécifications. Mais ces spécifications s'appuient sur l'ignorance dans laquelle étaient les concepteurs avant de démarrer le boulot!"
Les titres de la conférence de 1968 reflètent un certain degré d'incertitude: "Réflexions sur le séquencement de l'écriture d'un logiciel", "Vers une méthodologie de la conception", "Quelques réflexions sur la production de systèmes de grande taille". Certes la plupart des participants utilisent l'expression "Génie Logiciel" comme si elle allait de soi, et des lacunes sont déjà apparentes (on parle notamment assez peu du facteur humain), mais on peut deviner une véritable controverse sur les grandes lignes de ce qui préoccupera cette discipline.
En 1969 les titres des articles proposés ont gagné en assurance. "Critères pour un langage de description de systèmes", "La conception de systèmes très fiables en exploitation continue", etc. Mais c'est surtout en lisant entre les lignes qu'on décèle un changement, et notamment en lisant "The Writing of the NATO reports" de Brian Randell, une sorte de "making of" datant de 1996. Une drôle d'ambiance règne apparemment à la conférence de 1969, mais on ne peut que la deviner dans la description à demi-mot qu'en fait Randell:
L'acte de naissance définitif du Génie Logiciel ayant ainsi été associé à un acte de censure, Randell ajoute qu'il s'interdit pendant la décennie qui suivit d'utiliser le terme, le jugeant injustifié. Il n'acceptera de revenir sur cette décision que pour une conférence marquant en 1979 le dixième anniversaire de Rome, où il profita de l'occasion pour adresser à Barry Boehm, alors la "nouvelle star" de la discipline, une série de piques, que Boehm "ignora soigneusement, je suis navré de le rapporter, à moins qu'il n'ait pas été en mesure de les reconnaitre comme telles".
Le terme "crise du logiciel" est contemporain d'une autre expression certainement plus familière, "Génie Logiciel", formulée en 1968 lors d'une conférence organisée sous les auspices de l'OTAN. La seconde fut proposée comme solution de la première.
La Crise se manifestait par divers aspects. Les projets de développement dépassaient les délais et budgets impartis, les logiciels produits étaient de mauvaise qualité et leurs performances insuffisantes, ils ne répondaient pas aux exigences exprimées, ils étaient difficiles à faire évoluer.
Il y eut non pas une mais deux conférences de l'OTAN sur le Génie Logiciel, à un an d'intervalle. Que se passa-t-il durant ces douze mois? Presque en filigrane du discours officiel, on devine un événement d'importance.
En 1968, la première conférence semble poser une question. "L'approche de l'ingénieur est-elle appropriée pour aborder le développement de logiciels?" Environ cinquante experts venus de onze pays sont présents. Parmi les participants on compte des sommités comme Edsger Dijkstra (connu pour sa campagne contre le "goto" et en faveur de la programmation structurée), Alan Perlis (créateur d'Algol et auteur de proverbes qui sont au logiciel ce qu'une certaine tradition japonaise est au jeu de Go) ou Peter Naur (co-crédité de l'invention de la notation BNF pour décrire les langages de programmation).
Les actes des deux conférences disponibles sur le Web, dans une version PDF d'une qualité remarquable alors que la plupart des documents de cette époque sont en général simplement scannés, donc non indexés ni "cherchables", méritent d'être lus avec attention; j'avoue ne les avoir que trop rapidement parcourus jusqu'à présent, en tout cas pas avec la minutie qu'un historien leur accorderait. On y trouve par exemple ce conseil de Peter Naur qui recommande de s'intéresser aux idées d'un jeune architecte, Christopher Alexander. Le même Alexander qui sera redécouvert vingt anx plus tard par un certain Kent Beck, donnant naissance au mouvement des Design Patterns. Structurés d'une façon très systématique, ils couvrent la quasi-totalité des préoccupations encore d'actualité aujourd'hui quant à la façon de mener des projets dans le domaine du logiciel.
Ces documents sont éloquents quant au degré de controverse que suscite la question du génie logiciel. Voici une citation d'un participant: "La chose la plus dangereuse dans le domaine du logiciel est l'idée, apparemment presque universelle, que vous allez spécifier ce qu'il y a à réaliser, puis le réaliser. Voilà d'où viennent la plupart de nos ennuis. On appelle réussis les projets qui sont conformes à leurs spécifications. Mais ces spécifications s'appuient sur l'ignorance dans laquelle étaient les concepteurs avant de démarrer le boulot!"
Les titres de la conférence de 1968 reflètent un certain degré d'incertitude: "Réflexions sur le séquencement de l'écriture d'un logiciel", "Vers une méthodologie de la conception", "Quelques réflexions sur la production de systèmes de grande taille". Certes la plupart des participants utilisent l'expression "Génie Logiciel" comme si elle allait de soi, et des lacunes sont déjà apparentes (on parle notamment assez peu du facteur humain), mais on peut deviner une véritable controverse sur les grandes lignes de ce qui préoccupera cette discipline.
En 1969 les titres des articles proposés ont gagné en assurance. "Critères pour un langage de description de systèmes", "La conception de systèmes très fiables en exploitation continue", etc. Mais c'est surtout en lisant entre les lignes qu'on décèle un changement, et notamment en lisant "The Writing of the NATO reports" de Brian Randell, une sorte de "making of" datant de 1996. Une drôle d'ambiance règne apparemment à la conférence de 1969, mais on ne peut que la deviner dans la description à demi-mot qu'en fait Randell:
Contrairement à la première conférence, ou il était tout à fait clair que le terme de Génie Logiciel reflétait l'expression d'un besoin plutôt qu'une réalité, à Rome on avait déjà tendance à en parler comme si le sujet existait déjà. Et, pendant la conférence, l'intention cachée des organisateurs se précisa, à savoir: persuader l'OTAN de financer la mise en place d'un Institut International du Génie Logiciel. Cependant les choses ne se passèrent pas comme ils l'avaient prévu. Les sessions qui étaient censées fournir les preuves d'un large et ferme soutien à cette initiative furent en fait dominées par le plus grand scepticisme, au point qu'un des participants, Tom Simpson de chez IBM, écrivit une superbe et courte satire intitulée "Masterpiece Engineering" (Ingénierie du Chef-d'Oeuvre).Un article qui parlait, par exemple, de mesurer la productivité des peintres en nombre de coups de pinceau par journée. Et Randell d'ajouter que les organisateurs réussirent à le "persuader" d'omettre cet article satirique de Tom Simpson des actes officiels!
L'acte de naissance définitif du Génie Logiciel ayant ainsi été associé à un acte de censure, Randell ajoute qu'il s'interdit pendant la décennie qui suivit d'utiliser le terme, le jugeant injustifié. Il n'acceptera de revenir sur cette décision que pour une conférence marquant en 1979 le dixième anniversaire de Rome, où il profita de l'occasion pour adresser à Barry Boehm, alors la "nouvelle star" de la discipline, une série de piques, que Boehm "ignora soigneusement, je suis navré de le rapporter, à moins qu'il n'ait pas été en mesure de les reconnaitre comme telles".
Ingénieur en logiciel, un métier sans histoire?
Souvent, pour prendre du recul par rapport au monde du logiciel, je m'évade vers d'autres disciplines. Au cours de ces balades, le paysage m'étant par définition étranger, j'ai le loisir de me comporter en touriste, sans me sentir aggressé lorsqu'une de mes idées toutes faites, confrontée à la réalité locale, se retrouve bouleversée.
Parmi les guides que j'affectionne, Stephen Jay Gould était particulièrement doué pour emmener le lecteur dans un coin intéressant de son propre fief, la biologie et l'évolution. J'ai surtout apprécié dans ses écrits l'usage qu'il faisait de l'histoire des idées scientifiques. Il n'avait pas son pareil pour montrer comment, loin d'être un inexorable progrès comme peut le laisser croire certaines images d'Epinal, de nombreuses découvertes sont le fait de curieux renversements, et bien souvent la lecture qui en est faite finit elle aussi à l'envers de la réalité.
Dans Aux Racines du Temps, par exemple, Gould revient sur les portraits souvent dressés de trois acteurs importants dans l'estimation de l'âge de la Terre et des débuts du "temps géologique", un débat qui est un précurseur important à l'acceptation des théories de Darwin: pour que l'évolution puisse avoir lieu, il faut que nos origines remontent à bien plus que la période donnée par la Bible, à savoir quelques milliers d'années seulement.
L'image d'Epinal de ce débat est celle de deux héros (Hutton et Lyell) triomphant, grâce à leur lucidité scientifique et leur courage exemplaire, du rétrograde et fondamentaliste Thomas Burnet. Gould met en évidence l'inspiration véritable, fortement naturaliste, des arguments avancés par Burnet, la forte emprise idéologique sous laquelle Hutton formula les siens ou le scepticisme de Lyell vis-à-vis des idées de Darwin. Le travail de Gould est minutieusement documenté, étayé notamment par une lecture de première main des textes originaux, lesquels éclairent de façon implacable sur les motivations véritables des uns et des autres.
A lire Gould, on comprend qu'il faut se méfier d'une interprétation trop simpliste de l'histoire des idées. Plus nous travaillons dans le monde des idées, plus les idées peuvent exercer sur nous un contrôle d'autant plus fort et d'autant plus insidieux que nous en ignorons les origines.
C'est à ce stade que souvent, loin de rester de simples promenades, ces lectures me ramènent indirectement à mon propre métier.
Je me fais parfois la réflexion que notre profession tourne résolument le dos à sa propre histoire. Je ne prétends pas être particulièrement bon élève de ce point de vue, et lors de mes courtes études, l'histoire était parmi mes points faibles. Je manque sans doute cruellement de culture générale, mais au sein de ma propre profession, je me fais parfois l'impression du borgne au royaume des aveugles.
Ainsi des idées nous sont-elles présentées comme "neuves" et "révolutionnaires" alors que, pour qui s'est penché sur l'historique de la discipline, il ne s'agit que de réchauffé: des idées présentes dans tel ou tel dialecte de Lisp ou de Smalltalk depuis trente ou quarante ans. (Si vous ne me croyez pas, penchez-vous sur les comparaisons entre XML et les "s-expressions" ou entre la Programmation Orientée Aspects et les MOP ou Meta-Object Protocols.)
On pourrait aussi se demander combien, parmi ceux qui se réclament aujourd'hui du mouvement Agile, ont conscience de ses prédécesseurs, tels le RAD ou le Processus en Spirale dû à Barry Boehm. De façon générale, notre profession tend à considérer toute idée âge de plus de cinq ans comme obsolète et peu digne d'intérêt, et c'est sans doute en partie pour cela qu'on a parfois l'impression que notre industrie est aussi dominée par des cycles de mode que la haute couture.
Parmi les idées qui ont façonné les métiers du logiciel, une l'a fait de façon particulièrement forte et durable, l'idée du Génie Logiciel. Le logiciel relève-t-il vraiment d'une activité d'ingénieur? La question, lancinante, revient comme un serpent de mer dans les conférences consacrées au sujet, mais elle est rarement traitée sous un angle historique.
Au quotidien, trop rares sont ceux qui semblent conscients que le "logiciel" ayant lui-même une histoire d'à peine plus d'un demi-siècle, il a bien fallu inventer l'expression Génie Logiciel; que celle-ci ne va pas de soi, et que l'application des techniques de l'ingénieur au domaine du logiciel relève, non pas des lois de la nature, mais d'une décision à laquelle il a fallu rallier divers groupes: des militaires, des scientifiques, des groupes industriels.
Nous allons donc nous plonger dans la discrète histoire du Génie Logiciel. C'est une excursion qui a de quoi satisfaire les esprits curieux, même s'il devaient en ressortir plus convaincus que jamais de la pertinence de ce mariage. Mais nous verrons que cette histoire a de quoi alimenter bien des doutes...
Parmi les guides que j'affectionne, Stephen Jay Gould était particulièrement doué pour emmener le lecteur dans un coin intéressant de son propre fief, la biologie et l'évolution. J'ai surtout apprécié dans ses écrits l'usage qu'il faisait de l'histoire des idées scientifiques. Il n'avait pas son pareil pour montrer comment, loin d'être un inexorable progrès comme peut le laisser croire certaines images d'Epinal, de nombreuses découvertes sont le fait de curieux renversements, et bien souvent la lecture qui en est faite finit elle aussi à l'envers de la réalité.
Dans Aux Racines du Temps, par exemple, Gould revient sur les portraits souvent dressés de trois acteurs importants dans l'estimation de l'âge de la Terre et des débuts du "temps géologique", un débat qui est un précurseur important à l'acceptation des théories de Darwin: pour que l'évolution puisse avoir lieu, il faut que nos origines remontent à bien plus que la période donnée par la Bible, à savoir quelques milliers d'années seulement.
L'image d'Epinal de ce débat est celle de deux héros (Hutton et Lyell) triomphant, grâce à leur lucidité scientifique et leur courage exemplaire, du rétrograde et fondamentaliste Thomas Burnet. Gould met en évidence l'inspiration véritable, fortement naturaliste, des arguments avancés par Burnet, la forte emprise idéologique sous laquelle Hutton formula les siens ou le scepticisme de Lyell vis-à-vis des idées de Darwin. Le travail de Gould est minutieusement documenté, étayé notamment par une lecture de première main des textes originaux, lesquels éclairent de façon implacable sur les motivations véritables des uns et des autres.
A lire Gould, on comprend qu'il faut se méfier d'une interprétation trop simpliste de l'histoire des idées. Plus nous travaillons dans le monde des idées, plus les idées peuvent exercer sur nous un contrôle d'autant plus fort et d'autant plus insidieux que nous en ignorons les origines.
C'est à ce stade que souvent, loin de rester de simples promenades, ces lectures me ramènent indirectement à mon propre métier.
Je me fais parfois la réflexion que notre profession tourne résolument le dos à sa propre histoire. Je ne prétends pas être particulièrement bon élève de ce point de vue, et lors de mes courtes études, l'histoire était parmi mes points faibles. Je manque sans doute cruellement de culture générale, mais au sein de ma propre profession, je me fais parfois l'impression du borgne au royaume des aveugles.
Ainsi des idées nous sont-elles présentées comme "neuves" et "révolutionnaires" alors que, pour qui s'est penché sur l'historique de la discipline, il ne s'agit que de réchauffé: des idées présentes dans tel ou tel dialecte de Lisp ou de Smalltalk depuis trente ou quarante ans. (Si vous ne me croyez pas, penchez-vous sur les comparaisons entre XML et les "s-expressions" ou entre la Programmation Orientée Aspects et les MOP ou Meta-Object Protocols.)
On pourrait aussi se demander combien, parmi ceux qui se réclament aujourd'hui du mouvement Agile, ont conscience de ses prédécesseurs, tels le RAD ou le Processus en Spirale dû à Barry Boehm. De façon générale, notre profession tend à considérer toute idée âge de plus de cinq ans comme obsolète et peu digne d'intérêt, et c'est sans doute en partie pour cela qu'on a parfois l'impression que notre industrie est aussi dominée par des cycles de mode que la haute couture.
Parmi les idées qui ont façonné les métiers du logiciel, une l'a fait de façon particulièrement forte et durable, l'idée du Génie Logiciel. Le logiciel relève-t-il vraiment d'une activité d'ingénieur? La question, lancinante, revient comme un serpent de mer dans les conférences consacrées au sujet, mais elle est rarement traitée sous un angle historique.
Au quotidien, trop rares sont ceux qui semblent conscients que le "logiciel" ayant lui-même une histoire d'à peine plus d'un demi-siècle, il a bien fallu inventer l'expression Génie Logiciel; que celle-ci ne va pas de soi, et que l'application des techniques de l'ingénieur au domaine du logiciel relève, non pas des lois de la nature, mais d'une décision à laquelle il a fallu rallier divers groupes: des militaires, des scientifiques, des groupes industriels.
Nous allons donc nous plonger dans la discrète histoire du Génie Logiciel. C'est une excursion qui a de quoi satisfaire les esprits curieux, même s'il devaient en ressortir plus convaincus que jamais de la pertinence de ce mariage. Mais nous verrons que cette histoire a de quoi alimenter bien des doutes...
Inscription à :
Articles (Atom)
Articles
