[Note aux modérateurs: Ce post aurait sans doute eu sa place ailleurs, mais il semble que je ne puisse pas encore poster dans "Les Débats du Développement". Quoiqu'il en soit, n'hésitez pas à flinguer sans pitié si vous le jugez trop long ou sans d'intéret. Merci.]
Bonjour à tous,
j'aurais sans doute pu intituler ce post "Combustible polémique", mais mon but ici n'est pas de provoquer de réactions violentes ni de revendiquer de positions extrêmes. Je tiens d'ailleurs à préciser que je me considère comme un développeur sensible aux avantages des solutions OpenSource (quelqu'en soit la licence, GPL, BSD, Netscape, etc..). Par ailleurs, ce texte comportant quelques exemples issus de mon expérience personnelle, je vous prierais de bien vouloir les considérer comme de simples illustrations de mes propos, et de ne pas tomber dans le piège qui consisterait à croire que je cherche à imposer à la communauté de ce site mon opinion sur tel ou tel produit, librairie ou méthode de travail (ce qui serait ridicule de ma part).
Il y a quelques mois, j'ai eu à développer une application reposant sur l'analyse de code HTML. Mon premier réflèxe, bien sur, a été de rechercher sur Google les différents projets OpenSource mettant en œuvre un parser HTML, dans l'espoir de pouvoir le réutiliser dans mon application. J'ai donc consulté les documentations de plusieurs produits, comme la libxml2, la libgtkhtml, le parser de Mozilla, et une multitude d'autres, plus ou moins aboutis.
Après une sélection sommaire des quelques librairies semblant correspondre à ce que je recherchais, j'ai effectué une série de tests sur chacune d'elles, afin d'en comprendre l'utilisation, et d'en délimiter le périmètre fonctionnel. Au cours de ces tests, il m'est vite apparu, par exemple, que la libxml2 gérait correctement le HTML "propre" (genre XHTML), mais avait rapidement du mal avec le HTML du "monde réel" (souvent incorrect, du point de vue du W3C). Ce n'était bien sur qu'une demi-surprise, puisque cette librairie est avant tout un parser XML, étendue par la suite afin de pouvoir gérer "aussi" le HTML. De la même façon, la libgtkhtml m'imposait certaines contraintes, en particulier une forte dépendance vis-a-vis des structures de données Gnome, etc..
Je me suis rapidement rendu compte que dans tous les cas, le travail de "colmatage" et d'intégration allait me prendre beaucoup de temps. D'autant plus qu'il était nécessaire, dans la perspective d'une évolution de l'application, que je puisse également parser (je n'ai pas dit "interpreter", mais au moins "tokeniser") les définitions CSS ou les fonctions JavaScript qui pourraient apparaitre au détour d'une page.
J'ai donc pris une décision qui ferait sans doute dresser leurs cheveux sur les têtes des professionnels que vous êtes: développer mon propre parser HTML. Le système est basé sur une FSM (Finite State Machine, ou Machine à Etats), les transitions entre plusieurs tables d'états sont supportées via un simple système de stack, ce qui me permet d'avoir une state table dédiée au HTML, une autre pour les structures SGML, une pour les URI (ce qui n'est pas un luxe), une pour le JavaScript, et une pour les stylesheets.
Bien sur, j'ai eu droit aux railleries de circonstance ("tant que tu y es, refais aussi l'OS, les drivers Ethernet et la stack TCP/IP qui vont avec", etc..). Il n'empêche qu'aujourd'hui, je dispose d'un ensemble de classes répondant parfaitement à mes objectifs fonctionnels initiaux, et aux contraintes que je m'étais fixées (en particulier au niveau de la vitesse de traitement et de la gestion des erreurs). Plusieurs personnes sont intervenues sur le code depuis (principalement afin de développer de nouvelles state tables pour le support XML et SOAP), et l'apprentissage s'est fait sans mal. Le code (d'ailleurs minuscule puisque les state tables sont.. des tables) est correctement documenté, et maîtrisé de A à Z par au moins deux personnes.
Cette expérience m'a poussé à m'interroger sur l'intéret de la réutilisation systématique du code fourni par la multitude de produits OpenSource, qu'on trouve par exemple sur SourceForge. Je sais qu'il s'agit d'un sujet sensible, mais le leitmotiv bien connu du "il ne faut pas réinventer la roue" est une évidence un peu trop facile; je dirais même qu'il faut parfois avoir une certaine dose de culot pour oser s'octroyer le droit de la proférer à tout va.
La communauté OpenSource est un fantastique viver de développeurs; mais alors qu'aujourd'hui la plupart projets qui en sont issus supportent sans problème la comparaison avec leur pendant commercial (ou sont en passe de le faire, on peut citer l'exemple des browsers web, des composants XPCOM (Mozilla) vs. MSCOMM (Microsoft), des suites bureautiques et bien sur.. des OS eux-mêmes), on a parfois l'impression que la créativité qui les caractérisait traditionnellement est de moins en moins présente, et que leur dynamique de développement s'inscrit progressivement dans une logique d'inertie. Une grosse moyenne mobile, à l'échelle de la communauté toute entière. C'est sans doute ça qu'on appelle la maturité.
Mais c'est encore au niveau individuel (le développeur, ou le petit groupe de développeurs) que ce phénomène est le plus visible. L'exemple du parser HTML (peut-être un peu long, veuillez m'en excuser) en est tout-à-fait représentatif.
La plupart des intervenants sur ce forum sont sans doute des ingénieurs, soit par leurs études, soit par leur expérience qui dans un environement professionnel leur confère un rôle d'ingénieur. Ce rôle, justement, est d'identifier des problèmes, puis de proposer et de superviser la mise en place de solutions répondant à ces problèmes (généralement sous certaines contraintes techniques, de temps, du budget, etc..). Sans tomber dans les clichés folkloristes, on les suppose donc doués d'une certaine créativité, a priori dynamiques et ouverts d'esprit.
Pour avoir passé pas mal d'années en SSII (mais heureusement, au moins autant dans des Start-Up), je sais que beaucoup d'ingénieurs (souvent les plus jeunes, malheureusement) correspondent plus au prototype du "fonctionnaire", dans tout ce que ce terme peut avoir de péjoratif, qu'au profil que j'ai tenté d'ébaucher plus haut. Beaucoup d'entreprises technologiques sont demandeuses de talents, de gens qui osent proposer des solutions originales, parfois très simples, mais véritablement adaptées à des problèmes spécifiques, et se retrouvent avec de "jeunes actifs" en cravate PlayStation, qui ne savent qu'intégrer (souvent mal) des produits génériques (un peu de libgbidule par ici, un system() pour appeler la suite OpenBloatedTruc par là, etc..), le tout au nom de la réutilisation des composants logiciels. Quelle blague!
Et l'OpenSource dans tout ça ? Il est malgré lui au cœur du problème. A produire, inciter à réutiliser et à mélanger entre eux, encore et encore, les mêmes composants génériques, de façon systématique, jusqu'au point où on ne se pose même plus la question de savoir si on a vraiment besoin d'embarquer la moitié d'un serveur web pour faire un "Hello world", on oublie que certains problèmes spécifiques demandent des réponses.. spécifiques. La biodiversité s'éteint, les performances aussi, et la passion avec.
-pirus.
Partager