Je vous la refais rapidos : ça n’est pas parce que les gens « intelligents » (comprenez : au QI élevé) se couchent majoritairement tard que le fait de se coucher tard implique qu’on est intelligent.

Pas plus que le fait de posséder un Steinway de 2 mètres 80 ne fera de vous un grand pianiste. Ou pas plus que, comme dirait Eugène, le fait d’être mortel n’implique que Socrate est un chat.

Dans le métier, il y a des intervenants qu’on croise souvent, ils sont « consultants fonctionnels » (ou un titre approchant). Parfois, ils sont efficaces. Parfois moins.

Ça n’est pas pas toujours de leur fait, c’est toute la chaîne de l’AMOA qui est concernée (et en général, le client au premier chef). Mais c’est un autre sujet.

D’une manière générale, j’ai des réserves, non pas tant sur le rôle que sur le fait d’en faire un métier à temps plein.

Pour le dire autrement, un consultant fonctionnel de profession, ça me fait penser à quelqu’un qui n’aurait pas d’enfant, mais qui viendrait raconter par le menu comment on doit s’y prendre pour en élever — et accessoirement, se ferait payer pour ça.

Voilà pour mes two cents du jour.

Le MVC est un design pattern qui est l’abréviation de Modèle-Vue-Contrôleur, et pour une fois, en anglais ou en français, ça fait les mêmes initiales (Model-View-Controller), donc y aura pas de débat sur comment qu’on doit causer. On raconte que son créateur se nomme Trygve Reenskaug, me demandez pas comment ça se prononce — son créateur, ou disons son théoricien, car comme souvent, on ne l’avait pas forcément attendu pour opérer de cette façon, mais il a mis des mots dessus (ce qui ne diminue pas l’importance de son travail).

Pour tout dire, quiconque a fait seul dans son coin des sites web dynamiques en mettant un peu (beaucoup) les mains dans le cambouis des langages/bases de données/exploitations multiples des mêmes informations, etc, a de fortes chances d’avoir à un certain niveau commencé à appréhender plus ou moins consciemment le MVC – ou alors, il a vraiment beaucoup galéré, et il est un petit peu décédé à l’heure qu’il est.
Moi qui vous parle, enfin vous écrit, avant de lire quelques livres intéressants sur le sujet et de découvrir des frameworks, j’en étais arrivé à travailler systématiquement avec d’un côté des méthodes d’accès aux informations (à peu près bien abstraites du système de base de données), de l’autre des fichiers traitant les sorties (pour le web, pour le XML, pour des usages internes…), et au milieu un ou plusieurs points traitant les actions des utilisateurs et décidant ce qui devait être mis en œuvre.

Bien sûr, n’ayant pas conscience clairement des enjeux de cette division (faute entre autres d’avoir mis des mots dessus ; d’où l’importance de nommer), il traînait de nombreuses erreurs d’organisation affaiblissant souvent pas mal l’ensemble. Mais le fond était là : porté par la nécessité interne des traitements récurrents nécessaires pour une application web, j’avais fait un premier pas sans même le savoir, tel le Monsieur Jourdain des design patterns, dans le monde merveilleux du MVC.

Le MVC, ou comment diviser pour mieux régner

Précisons avant d’aller plus loin que comme tout design pattern, MVC n’est pas spécifiquement dédié à une technologie, un langage ou quoique ce soit.
Il concerne de droit toute application avec une interface Homme-Machine, comme on dit (enfin, on dit IHM si on veut avoir l’air au courant), et consiste en une sorte de paradigme de l’organisation de l’application, séparant les données et leur vie (modèle), leur présentation (vue), et la gestion des événements (contrôleur).

Séparer le modèle et la vue repose sur une exigence au fond assez simple, qu’on pourra schématiser comme suit : il faut traiter d’un côté le « fond », de l’autre la « forme ». Je recours aux guillemets, non pas pour pourrir la lecture, mais parce que l’utilisation de ces deux termes et leur séparation semblent aller de soi, or comme tout ce qui « va de soi », elles méritent d’être questionnées. Il est illusoire de croire qu’il y aurait d’un côté du « fond » (du contenu, de la pensée…) et de l’autre de la « forme » (l’expression, qu’elle soit écrite, orale, artistique…)
Autant supposer qu’on peut sans autre forme de procès séparer la musique du son, ou l’objet de sa manifestation — ce fantasme de séparation n’est en fait qu’une autre version de l’illusion platonicienne de la chose en soi, « vraie » chose dont le phénomène serait une version dégradée dans notre pauvre monde d’apparences.
Non pas qu’il n’y ait pas un intérêt théorique capital à pouvoir considérer séparément ces aspects ; mais dans la réalité, je vous le dis, croyez-moi sur parole, le phénomène épuise tout ce qu’il y a à être de la chose, et la forme, comme je l’ai déjà formulé dans une note précédente, et exactement forme de son fond et réciproquement. Bref. J’ai clairement entamé un autre post ici, qui verra peut-être le jour une autre fois. Revenons à nos moutons.

Nos moutons sont le M, le V, et le C. Il n’aura échappé à personne, du moins à personne qui aura lu avec un minimum de concentration le billet précédent sur les prises électriques et les grille-pain (mais je reconnais qu’il faut du courage), qu’une organisation isolant bien ces trois aspects d’un programme est comme l’archétype du découplage.
Votre modèle (en gros, les données) peut changer de principe de stockage, de nature même si ça vous chante, pour peu qu’il soit correctement interfacé avec les autres couches du MVC, elles n’y verront que du feu. Le centre nerveux de votre application (le contrôleur, qui réagit aux actions de l’utilisateur et distribue les réponses) peut de son côté traiter n’importe quel type d’entrées et rediriger les sorties vers n’importe quel affichage, i.e. les vues. Vues qui de leur côté se contentent de mettre en forme (grosso modo) des informations, indépendamment de leur origine. J’ai failli dire « se contentent d’afficher », mais en fait, contrairement à ce que son nom laisse croire, une « vue » au sens du MVC ne résulte pas nécessairement en quelque chose de… visuel. Une vue peut-être par exemple un fichier XML, qui vivra sa vie ensuite selon le client (au sens informatique) qui l’a requis.

Quand l’intelligence gagne la matière

L’intérêt très concret de l’application du MVC est qu’il isole les opérations, donc que chacun n’a à s’occuper que de sa partie. Et comme dans la vie, c’est toujours mieux quand chacun ne s’occupe que de ce qui le regarde. Dans ma Normandie natale, on dit « Chacun son champ, les vaches sont bien gardées« . Eh bien on ne peut mieux formuler le principe du MVC.
En termes de développement, cette division conceptuelle vise à organiser les rôles par fonction, et à traduire les différences de nature en séparations opérationnelles. Comme si on faisait rentrer dans la chair du code, qui a priori n’en a que faire, un peu du sens des objets qu’on manipule. En contre-partie, dans un effet de résonance sémantique, j’irais bien jusqu’à dire : de récompense sémantique, le code, initialement « bête », gagne en intelligence d’organisation et d’évolution. Risquons la formule : bien utiliser le MVC, c’est insuffler de l’âme dans la matière. Ouaip. Pas moins.

L’ultime intérêt, non des moindres, est pédagogique : en s’efforçant d’appliquer cette discipline de conception et d’implémentation, on s’oblige à bien comprendre ce qui fait quoi dans son application. Et croyez-moi, c’est pas de la tarte.
Mais, une fois encore, une bonne méthode appliquée avec constance finit par insuffler plus que du mécanisme, et crée de l’intelligence. Et pas que dans le code. Dans le codeur également. C’est toute la puissance de la méthodologie : des idées régulatrices qui dirigent vers un endroit. Et même si on ne sait pas précisément où est l’endroit, on peut travailler à avancer dans la bonne direction, et à bien arpenter le chemin.
Car pour finir sur une touche étymologique du meilleur aloi, c’est précisément de là que vient le mot méthode : μέθα (méta, qui suit) οδός (odos, le chemin).

___________________________________

Image empruntée ici : http://www.marriedtothesea.com/archives/2007/Aug/

« Réinventer la roue » (ou « rihinveinte zeu ouhile », pour les bilingues), c’est perdre du temps sur quelque chose qui a déjà été fait, bien fait, mieux fait, bref, faire un travail inutile. En programmation, c’est même un antipattern célèbre. Si on peut lui reconnaitre dans une certaine mesure un intérêt pédagogique (l’impétrant développeur, en passant du temps sur une fonctionnalité déjà réalisée, s’initie au code et à sa logique – pour peu qu’il soit guidé), il est clair qu’on déconseille fortement de réinventer la roue. Si ça a déjà été inventé, coco, pourquoi perdre du temps à le refaire, d’autant qu’il y a fort à parier que tu le referas moins bien. En effet, non seulement la roue a déjà été inventée, mais depuis le temps, elle a été perfectionnée.

La bonne pratique est donc de capitaliser, comme on dit, sur ce que les autres ont déjà fait, testé et éprouvé.
En programmation, où l’Histoire est encore fraiche et où tout va très vite, ces « autres » sont parfois des contemporains (voire sont plus jeunes que vous ; sales jeunes), mais pour généraliser on peut dire que cette bonne pratique consiste à apprendre de ce qui a été fait, donc apprendre du passé, des générations précédentes, en d’autres termes : de ses aînés. Ce passé qu’on peut plus ou moins consciemment faire fructifier a un nom : la tradition.

L’Histoire se répétant, chaque nouvelle génération a une tendance plus ou moins forte à vouloir se défaire de la tradition, comme une transposition à l’échelle socio-culturelle de la crise d’adolescence, où le besoin de conquérir son individualité se traduit parfois par des chocs violents (tant il est évident que pour chaque jeune, les vieux n’ont vraiment rien compris, et ne peuvent de toutes façons pas le comprendre lui).

Il y a pourtant une réalité douloureuse, c’est que globalement, vu que l’Histoire n’a pas exactement commencé hier, ni même à la naissance de Bill Kaulitz/Brian Molko/Kurt Cobain/Robert Smith/John Lennon (choisissez pour votre génération ou celle qui vous suit), vu que l’humanité, donc, a quelques heures de vol derrière elle, excusez du peu, il y a de fortes chances que tout ait déjà été fait.

Connais tes classiques

Bien sûr, l’accélération (on va appeler ça comme ça) de l’Histoire dûe à la technologie au sens très large, donc depuis la fin du XIXème siècle, fait que dans pas mal de domaines, le passé est bref. Ça a un côté assez sympathique, on peut croire un peu qu’on défriche des choses — et ça n’est en partie pas faux —, mais il ne faut pas non plus se faire avoir par une courante illusion d’optique : même si concrètement le contenu du savoir/de la technologie en question est « différent », dans l’histoire du savoir, on n’invente que très rarement quelque chose. Pour ne pas dire jamais. La plupart du temps, on repasse en fait par des chemins qui ont déjà été empruntés, même si on ne le sait pas (et dans ce cas, en un sens, on peut se retrouver à réinventer la roue).

Cette illusion repose principalement sur un aveuglement, dû à un manque de connaissance du passé, et la bonne pratique qui préconise de ne pas réinventer la roue exhorte donc à ouvrir les yeux. Mais pour ça, comme on dit, il faut connaître ses classiques. Lire, écouter. Plus tu connais le passé, plus tu maîtrises le présent, plus tu façonnes le futur comme tu le veux (je devrais écrire des slogans pour ERDF, moi).

Ça peut avoir l’air déprimant comme ça, mais ça ne l’est que si l’on se berce de l’illusion (une autre) qu’on est le premier de l’espèce humaine et que tout nous a attendu. Il faut se réveiller. Personne ne nous a attendu, et les morts sont plus forts que les vivants.
Mais en fait, c’est très bien, et ça laisse quand même de la place. Parce que l’histoire est une perpétuelle redigestion, qu’elle engendre quand même du nouveau, et qu’emprunter un chemin qui a déjà été foulé est toujours un nouveau périple.

La morale de cette histoire (qui n’en est pas une), c’est que quand l’ego a réussi à faire le deuil de sa toute-puissance, à entrer dans son humilité, et pas au sens chrétien du terme, alors les choses intéressantes peuvent éventuellement commencer.
J’aborderai probablement une autre fois le rapport à la tradition, qui n’est évidemment pas univoque et ne doit pas consister en une soumission absolue (car, comme disait l’autre, la tradition ça peut aussi être de la paresse ou de la négligence. Mais pour contester ou dépasser, il faut connaître ce qu’on prétend dépasser.

__________________________

Illustration fort à propos trouvée fortuitement ici : http://plennevaux.be/alexandre/general/monocycle-par-ben-wilson/

Ça fait quelque temps que je fomente cette note. A force d’entendre répéter ça et là que telle ou telle chose n’est qu’une question de bon sens, et malgré des années de sommeil (pas si dogmatique), j’ai fini par remâcher quelques vieilles dispositions anti-cartésiennes dont je vais vous abreuver pas plus tard que tout de suite.

Car oui, s’il n’a bien évidemment pas inventé le bona mens, c’est notre ami Descartes qui installe le « bon sens » comme le fourre-tout le plus prospère de l’histoire de la pensée (occidentale) moderne.

La première phrase du premier chapitre de la première partie du fameux/fumeux Discours de la méthode assène anéfé sans autre forme de procès que, selon la formule que chacun connait sans la connaitre :

Le bon sens est la chose du monde la mieux partagée 

Il ne faut pas cela dit prendre Descartes pour plus bête qu’il n’est ; son bon sens n’est pas le pur et mou « sens commun », mais une disposition de l’esprit que chacun peut trouver, une sorte de sagesse de l’évidence (et sans mauvaise blague, Dieu sait que c’est son truc, à René, l’évidence).
Tout comme faire simple est parfois plus complexe que faire compliqué, faire comme on dit « preuve de bon sens » n’est pas si aisé. C’est que l’évidence cartésienne est une sorte de préfiguration du résultat de la réduction phénoménologique (enfin, soyons honnêtes, ce sont les phénoménologues qui réinvestissent Descartes un peu moins de trois siècles après).
Il y a le « bien connu », trop connu, qui camoufle, comme le gros drap poilu et poussiéreux d’années de sensations non questionnées, la phénoménitude du phénomène (Ségo, sors de ce corps).

Mais quand même, le bon sens selon Descartes est bien à la portée de tout le monde. C’est la chose du monde la mieux partagée. En une phrase Descartes signe l’ouverture de la modernité, faisant d’une « qualité » inhérente à tout être humain le butoir à la régression à l’infini du questionnement philosophique : au bout d’un moment, il ne faut plus se demander pourquoi, car c’est bien évident que ça n’est qu’une question de bon sens. Jvous la fait à l’arrache des grands jours, bien sûr, mais l’argument ontologique (qui sert de base à une preuve de l’existence de Dieu) ne vaut pas deux cacahuètes de plus.

Un coup de poing sur la table

Eh oui. Songes-y, toi le voyageur mystérieux (ouaip, j’ai envie de vous apostropher comme ça), si enfin il suffit de faire preuve de bon sens, il n’y a plus rien à discuter. Et si tu ne comprends pas, c’est que tu n’as pas, ou pas assez, de bon sens. Prends-toi ça dans ta face. Et si tu critiques ou te révoltes, c’est que tu ratiocines, que tu coupes les cheveux en un multiple de deux, bref, que tu es du côté de la non-clarté (oui, le « côté obscur », ça a des sortes de connotations dont je vais me passer pour ce soir), donc ferme ta mouille.
En quoi le recours à l’argument, que dis-je, le coup de poing sur la table de l’invocation du bon sens, est un double geste démagogique — le bon sens est la sagesse des humbles, de la France d’en bas, pas des intellos parisiens — et autoritariste : c’est en fait un ordre impératif de se taire.

Comprenons-nous bien : je force le trait, comme souvent, pour donner de la chair au propos. Je reconnais tout à fait, je l’ai évoqué plus haut, la difficulté de la simplicité, et j’admets qu’on a souvent tendance à faire d’emblée compliqué. Je suis assez d’accord pour mettre la sagesse du côté du moins, ou plutôt du kairos, de la juste mesure, quoi (à strictement parler, le saisissement du bon moment, qui est un art délicat). Et je sais bien que Descartes n’aurait pas complètement dit le contraire, mais j’aime bien l’avoiner, car sous maint aspect il nous a bien plombé. Enfin ça n’est pas l’objet.

Et le bon sens, alors ? Je n’ai rien contre le bon sens. Quelque soit ce qu’on entend par là, presque. C’est plus son invocation, utilisée comme stratagème rhétorique, qui a tendance à me rendre un tantinet suspicieux.

Ce sera donc le conseil du jour : tout comme quand vous entendez parler de carreleur, chaque fois que soudain un appel au bon sens surgit, entendez-le bien, mais ne vous faites pas moucher.
Le bon sens n’est pas un argument en soi. Et surtout : il ne va pas de soi (normal, sinon on n’aurait d’ailleurs pas à y faire appel…), donc son irruption dans un discours ne doit pas mettre fin à toutes les questions.
En fait, il ne vaut pas plus qu’un coup de poing sur la table. Alors ok, un coup de poing sur la table, des fois c’est utile, mais il faut savoir où on est et ne pas prendre ça pour un argument.
Or, on peut être intimidé par les coups de poing, mais on a toujours le droit de demander des arguments.

Je n’aborderai pas ici le débat, en partie stérile, consistant à se demander s’il faut traduire ou non tous ces termes et/ou créer des équivalents en français quand il n’y a pas de mot existant. Une langue vivante est, comme son nom l’indique, vivante (eh ouaip, ne me remerciez pas), comme tout organisme elle mue, agrège des éléments, transforme de la matière en d’autres choses, et c’est très bien (mieux : c’est vital — une langue que ne bouge plus est, comme on le dit fort bien, une langue morte).

Non, je vais juste ici évoquer quelques uns des mots qu’on pratique beaucoup en environnement professionnel, ceux qui ont pour mon oreille un peu bizarre des résonances particulièrement drôles ou poétiques. Ça me donnera au passage l’occasion de parler un peu d’un framework que j’aime bien (voir ici, ici, ou ici). On pourrait appeler cette liste « les 10 termes à connaître pour speaker fluemment le Symfony in le texte ».

• autoload : ne me demandez pas pourquoi celui-là me plait, il y a des chances que ça ait à voir avec Goldorak (autolargue, quoi).  En ce qui nous concerne, l’autoload est une fonctionnalité un petit peu magique qui dispense le développeur d’inclure explicitement chacun des fichiers définissant les classes dont il a besoin, le framework (chez nous, c’est Symfony, des fois que je ne l’aurais pas dit) se chargeant à chaque nouvelle instanciation d’objet de fouiller les répertoires qui vont bien à la recherche du fichier nécessaire et de l’inclure dans votre dos sans que vous ayiez à vous en soucier.
• bootstraping : souvent utilisé dans un discours de vérité pour en jeter un max, le bootstraping est littéralement laçage de chaussure (ou serrage de sangle de botte…) Les bootstraps sont concrètement des anneaux cousus sur le rebord des bottes, qu’on utilise pour s’aider à les chausser. En anglais courant, le verbe bootstrap signifie d’ailleurs « se débrouiller tout seul ». Pour la fine bouche, signalons que dans la littérature anglaise le verbe est également une référence aux aventures du baron de Münchhausen qui, embourbé dans un marécage, s’en sort en se tirant lui-même par ses bottes pour se propulser dans les airs…
  « Bootstraper », puisqu’on l’utilise bien entendu comme verbe francisé, consiste à démarrer le boulot en en prémâchant l’essentiel, pour obtenir rapidement une base pouvant servir au développement d’une application plus puissante par la suite.
• cécé : ou « cici », si on le fait à l’anglaise ; abbréviation et alias de la commande Symfony clear-cache (puis plus récemment cache:clear) utilisée pour clearer le cache (le vider, quoi). On doit entendre chez Sensiolabs environ 167 fois par jour « t’as fait un cécé ? ».
• crud : à prononcer « crude », ou « creude », bien sûr. Acronyme de Create-Retrieve-Update-Delete, qui sont les quatre fonctions de base d’une interface simple d’administration de données.
• fixtures : toujours un peu difficile à dire pour les français, les fikstcheurzes sont des données servant à tester et/ou initialiser une application, stockées dans un format simple à éditer et à utiliser pour des injections automatiques (voir populate plus bas).
• helper : j’aime bien l’idée d’ « aideurs » (j’imagine que l’administration nous ferait dire « aidants ») qui avec leur petits bras muskés font des trucs pour toi. Un helper est en effet une petite fonction destinée en général à retourner du code HTML répétitif, construit avec des paramètres ou propriétés d’un objet qu’on lui passe.
• hydrate : liquide et poétique image qui touche au sublime : « hydrater un objet » consiste à lui attribuer des valeurs qu’on a récupérées en vrac par ailleurs (pour faire très simple), cette attribution devant être « intelligente », c’est-à-dire qu’elle doit faire correspondre à la bonne propriété la bonne valeur. On peut « hydrater à la main », ce qui n’a rien à voir avec une crème de jour, ou recourir à des fonctions qui mâchent le travail.
• populate : autre métaphore que j’affectionne particulièrement, qu’on emploie un peu indifféremment en anglais ou dans sa version française ( « peupler », ou le néologique « populer »). Peupler une base de données consiste à lui injecter des données de tests ou des données initiales nécessaires à l’application (utilisateurs, contenus de départ…) ; pour faciliter la vie des développeurs, il existe dans Symfony des façons d’automatiser cette action pour pouvoir la répéter en deux coups de cuiller à pot et insérer des fixtures en une seule commande.
  Il existe aussi la variante « repeupler« , qui désigne le fait de réafficher les données saisies par l’utilisateur dans un formulaire s’il contient des erreurs ou doit être complété. On a tous un jour expérimenté la douleur de l’absence de repopulation, quand on a passé du temps à remplir un formulaire, qu’on valide, qu’il est refusé pour une quelconque raison, mais est réaffiché tout vide, et qu’on doit tout ressaisir… Vous pourrez maintenant hurler « IL N’A PAS ÉTÉ REPEUPLÉ, BORDEL DE M… ! »
• routing : celui-là aussi on le traduit peu (le « routage » gardera quoiqu’on en dise toujours une connotation de service postal). Le routing est le mécanisme qui réécrit et/ou traduit les urls (selon le sens où on le regarde) pour permettre de paramétrer des adresses, comme on dit, plus sympathiques pour les utilisateurs et les moteurs de recherche (respectivement : user-friendly, et search-engine-friendly ; ouéééé, copaaaing !) Il est lié à ce qu’on appelle la réécriture d’url, qu’on dit très souvent à l’anglaise aussi : l’iouharelle riraïtingue.
• sandbox : littéralement « bac à sable », désigne une mode autonome de distribution d’une application, pour faciliter son installation et permettre des tests où les risques d’impact pour le reste du serveur sont limités sinon nuls. En d’autres termes : pour faire joujou dans son bac à sable où on peut tout crader sans gêner personne.
• scaffolding : image très sympathique, qu’on pourrait traduire par « échaufadage ». Assez proche du bootstraping, le scaffolding est plus spécifiquement lié à la façon d’exploiter la structure d’une base de données. Il se base sur une description formalisée de cette structure (dans Symfony, par exemple, dans un fichier schema.yml) pour générer automatiquement une interface d’administration crud (voir plus haut). C’est ce que fait le bien nommé admin generator,  affectueusement appelé admin gen (prononcez « admine jène »), dans Symfony. En quoi on peut dire : « l’admin gen, ça consiste à bootstraper ton backoffice en faisant du scaffolding avec des interfaces crud ».
  Cpas beautiful, ça ?

Titiou Lecoq nous y explique pourquoi le « réseau social » Twitter « ne va pas conquérir le monde », en reprenant l’argument (fort juste au demeurant, et déjà développé notamment ici http://www.ecrans.fr/Sur-Twitter-on-se-suit-sans-trop,7483.html) selon lequel il ne faut pas se laisser avoir par l’illusion d’optique qui cache qu’en partie que le phénomène Twitter est créé et entretenu par une toute petite frange de la population internetesque, celle qui l’utilise, et qui en parle, et qui est la population qui parle sur internet, et qui parle de son utilisation dans une sorte de cercle sans aucun doute égocentré (quelle surprise) se nourrissant lui-même à l’infini ou presque.

L’article de slate.fr est bien étayé par ailleurs ; il rappelle, s’il en est besoin, que la majorité des internautes n’utilise pas Twitter, n’est pas drogué de l’info en continu, et que si vous n’avez pas des infos capitales à y poster, ça n’est effectivement pas d’un grand intérêt (mais j’ai comme l’impression qu’on dit là « si tu ne dis rien d’intéressant, ça n’est pas intéressant », ce que je ne me risquerai pas à contredire malgré mon goût pour la rhétorique).

Il pointe aussi le fait que tout ce qui relève de l’info pratique peut tout à fait être répandu par d’autres biais (Facebook par exemple), ce que personne n’a cherché à nier non plus – heureusement que les infos peuvent être diffusées par plusieurs médias, sinon on serait quand même dans la mouise.

Il pilonne enfin — c’est sa thèse de fond, confer l’image d’illustration choisie — la sphère webjournalistique/blogueuse et sa propension souvent ridicule à gonfler son égo jusqu’à l’explosion, ou à chercher à montrer qu’on a bien la plus grosse, point sur lequel il n’y pas grand chose à redire non plus.

Un mauvais procès

Bref, je suis d’accord avec l’essentiel de ce qui y est écrit.

Mais l’article me semble tout de même trahir une incompréhension de la chose Twitter, souvent entretenue par ses propres défenseurs d’ailleurs. Non, Twitter n’est pas un réseau social. Il n’est pas destiné à concurrencer ou remplacer Facebook, MSN, l’email ou les blogs — ou alors, c’est une erreur stratégique qui frôle la débilité.
Si Twitter ambitionne d’être un réseau social, on peut dire en effet qu’il est mal barré : il faut rapidement supprimer la limitation de caractères, probablement rendre bijective la connexion entre les utilisateurs , rajouter plein de gadgets susceptibles d’attirer et de faire rester tout ce qui relève du ROFLMAO ou du MER IL ET FOU (désolé, il fallait que je le fasse)…

Mais non. Twitter est un outil polymorphe qui, comme j’essayais de le pointer l’autre jour ici, sert à ce qu’on en fait, ni plus, ni moins. Rien d’étonnant donc à ce que les « professionnels du web », qui sont en effet les premiers utilisateurs, aient pour l’instant surtout développé, à leur corps défendant ou non, le côté info en temps réel, promotion et branding, et clash deupoinzéro. Pour paraphraser une sentence que j’aime bien : on a le Twitter qu’on mérite.

Enfin, comme annoncé en début de post, L’article de slate.fr illustre le phénomène que je décrivais, et qu’on peut (re)formuler comme suit : si on ne prend pas un peu, voire beaucoup, de temps pour expérimenter Twitter, on pourra difficilement avoir compris à quoi ça pouvait servir.
Cela dit, je tiens à ajouter, si ça n’est pas assez clair, qu’il n’y a aucune obligation à se mettre à Twitter ni même, pour peu qu’on l’ait expérimenté suffisamment, à y rester, à trouver ça intéressant ou génial.
Sans même parler de l’ambiance facilement rebutante qui peut y régner quand nos grands blogeurs hexagonaux ou autres se démontent verbalement la tête ou exhibent leurs parties (en même temps, personne ne vous oblige à suivre des boulets infatués, hein…), je peux tout à fait concevoir qu’on ne trouve, pour le dire ainsi, rien à en faire, après tout. Pour répondre à la question du titre : non, Twitter n’est pas forcément pour tout le monde. Si ça ne vous intéresse pas, ça n’est ni un crime ni une tare.

En revanche, annoncer que Twitter ne peut servir à « créer du fond » et que « la limite de signes interdit la création de contenu », c’est montrer qu’on n’est pas rentré dedans (une fois encore, ça n’a rien d’obligatoire ou d’indispensable), et qu’on rate quelque chose sur la création (oui, c’est un gros mot) d’une façon générale.
Que la limitation à 140 caractères soit une sacré contrainte, c’est évident, mais c’est aussi un défi intéressant.
Cela étant, dire qu’on ne peut pas créer du fond (j’adore cette expression, ça me fait penser à une valise à double-fond) c’est faire un mauvais procès à Twitter, et lui reprocher de ne pas être ce qu’il n’a pas à être : il ne remplacera jamais le cadre d’un blog ou d’autre chose pour une certaine forme d’écriture. Le fond est toujours fond de sa forme, donc les contraintes d’un mode d’expression influent sur ce qu’on en peut faire, voire le structurent fondamentalement.

Nous sommes donc bien d’accord, je crois, sur le fait que penser que Twitter ou le « web de flux » sont supérieurs au web tout court, voire destinés à le remplacer, n’a pas vraiment de sens, car les modes et les niveaux d’expression s’additionnent, ils ne se remplacent jamais vraiment. Mais je ne sais pas trop qui a ce discours sur Twitter — pas moi en tout cas. Et ceux qui l’ont éventuellement sont de bien piètres avocats.

Toutes ces considérations, enfin, ne contredisent en rien le fait que le « niveau », sur Twitter, est bien inégal, voire pas terrible la plupart du temps. Mais ça n’est pas parce que les romans de gare pullulent qu’on doit jeter ou déprécier toute la littérature.

__________________________

La jolie illustration a été subtilisée ici.

Disons que mon point est le suivant : dans le développement d’applications, comme dans tous les métiers où il y a une part de « création » — ou disons de poïesis, pour se la jouer à la Aristote —, règne une sorte de flou, entretenu en général inconsciemment par les acteurs de ces métiers, sur le statut de ceux qui « produisent ».

Tantôt ils sont traités comme de simples exécutants, tantôt comme plus, voire bien plus, que cela, et on a conscience de leur rôle de créateur au sens large, voire d’artiste ; on retrouve par exemple clairement cette séparation en graphisme, où on distingue la créa de l’exé.
Ne parlons pas de susceptibilités individuelles plus ou moins mal placées qui s’additionnent à ces considérations, ça nous évitera d’y passer la nuit. Nommons en revanche tout de suite (mieux) le couple qui fonde cette histoire : l’art et l’artisanat.

Pour une fois, le français est plus près de l’ambiguïté intrinsèque du réel que l’anglais, qui sépare très violemment, dans un geste presque germanique, art et craftwork, sans qu’on entende un quelconque lien de famille entre les deux — et en plaçant clairement le second du côté du travail.

En français, les deux mots sont très proches ; ils portent assez bien toute la problématique dans son non-dit, ou son peu-dit. Il y a d’un côté l’artiste, de l’autre l’artisan. Bien évidemment, rien n’empêche l’artisan d’agir par moments comme un artiste, ni l’artiste de mettre de temps à autres un costume d’artisan (c’est même fréquent, spécialement dans les arts dits plastiques). Mais socialement, la distinction est capitale.

Sans rentrer dans des considérations sociologico-historiques interminables, et sans faire du Norbert Elias à la petite semaine, notons que le concept d’artiste n’existe pas vraiment chez nous autres occidentaux avant l’époque romantique, disons à la hache le début du XIXème siècle. Il y a évidemment (l’histoire réelle ne marche pas avec des dates couperets toute simples et bien découpées) des précursions, pour inventer un mot, dans les siècles qui précèdent (il suffit de penser à Dürer ou Poussin), mais globalement, avant le XIXème siècle, la conscience d’agir comme artiste n’existe pas.

Aucun des maîtres qu’on reconnait actuellement ne se serait défini comme artiste, ou aurait dit que son « métier » était d’être artiste. Ce qu’ils faisaient était certes un métier, mais pas très valorisé, et dépendant de mécènes de niveaux divers, et en tous les cas, de commandes. Car c’est le fond de la question : c’est bien d’être un artiste, peu importe ce que cela veut dire, mais il faut comme dirait l’autre mettre du beurre dans les épinards.

L’œuvre sur commande

Sauf à être rentier, donc, avant l’époque moderne, celui qui œuvre dans un domaine qu’on dirait aujourd’hui artistique (musicien, peintre, sculpteur…) travaille sur commande. Michel-Ange et ses potes dans la chapelle Sixtine, Mozart pour toutes ses œuvres (pas seulement son Requiem, à peine commencé), tous exécutent une commande, se font payer (plus ou moins bien, à 365 jours fin de mois parfois), et pour aussi inspirés et géniaux qu’ils soient, sont à peine mieux considérés que des valets de chambre dans l’échelle sociale, et il ne leur vient pas à l’esprit de peindre ou composer hors de ce cadre.

Même si je force un poil le trait, et s’il n’est pas du tout question de dire que ce qui a été produit dans ce contexte ne peut pas être parfois de l’ordre du chef-d’œuvre, ce qui importe c’est la conscience de soi qu’ont ces gaillards. Si le larron Mozart a des  tourments existentiels, jamais il ne prend la pose d’un « artiste », encore moins incompris ou malheureux.
Cette posture n’éclot qu’au siècle suivant, avec entre autres des allemands (tiens donc) comme Beethoven, et surtout Schubert. Dans le Massin, il est dit que Schubert est le premier musicien à écrire symptomatiquement « pour lui ». L’histoire dit qu’il commença un opéra (Le comte de Gleichen), sans commande et que, bien que la partition en cours soit refusée par la censure, il le termina, affirmant ainsi une individualité et une incarnation de la création comme telle, hors de tout métier.

Si historiquement ça n’est peut-être pas complètement exact, le geste est tout de même fondateur, et signe d’un virage : celui de l’apparition d’une conscience d’être-artiste, qui n’a pas à souffrir les contingences pécuniaires d’un mécène plus ou moins cultivé, et doit s’exprimer quoiqu’il advienne, car elle procède d’une nécessité qui transcende le trivial et le quotidien.

D’où le personnage de l’artiste maudit, pauvre slash malade slash méconnu-de-son-vivant, emblématique de ce nouveau type social.
Difficile d’imaginer qu’il pourrait exister un « artisan maudit »… Dans notre partition, l’artisan c’est l’exécutant, le technicien, le laborieux, qui répète des gestes appris, parfois jusqu’à un certain degré de beauté, mais jamais hors de l’immanence du travail. En tant qu’artiste, en revanche, on se doit d’être affranchi de ces contraintes.

Je ne m’attarderai pas non plus aujourd’hui sur l’évolution historique et culturelle qui a voulu qu’on institutionnalise et qu’on étatise l’art, et qui contribue à une sorte, sinon de perversion, du moins de torsion assez ambivalente de concept, ça sera peut-être pour une autre fois.

Toujours est-il, pour en revenir au sujet de départ, qu’il est de toute évidence difficile, voire impossible car antinomique, de concilier art et métier, c’est-à-dire art et artisanat.
Non pas, une fois encore, que les deux ne se mélangent pas via de nombreux points de contact, mais parce que le pragmatique va toujours très rapidement supplanter le poïétique, pour des raisons simples qu’on déplorera peut-être mais qui veulent que votre patron, sauf exception étrange, ne vous paiera pas pour faire de l’art.

Et quand bien même il le ferait, au fond, cela invaliderait d’emblée votre « œuvre », parce que d’une certaine manière, pour que l’art soit art, il ne faut pas que cela soit payé et que, pour céder à la formule facile, on ne fait pas d’art à la commande.

Comme je ne suis pas mécontent du début de la série consacrée à Symfony et à ma chère mère, et qu’il ne se passe pas une semaine, que dis-je, un jour sans qu’ici et là, y compris au bureau, la question d’expliquer Twitter ne vienne sur le tapis, jme suis dit comme ça, en mon for intérieur où je me parle beaucoup (en me tutoyant, ce qui parfois me laisse perplexe), que j’avais bien matière à noircir quelques div de considérations puissantes et péremptoires sur le sujet.

Entendons-nous bien : en octobre 2009, il n’est plus question de prétendre faire découvrir Twitter, la fréquence d’évocation du site de gazouilling étant à peu près quotidienne sur tous les médias, y compris les plus grand public, nul doute qu’à ce jour à peu près tout le monde sait que Twitter existe, du moins toute personne qui a un rapport fréquent à notre ami l’internet. Mais bon, tout le monde sait aussi que e=mc², ça ne veut pas dire que chacun sache expliquer vraiment ce que ça signifie pour autant (et je vous rassure, à part traduire les signes e, m, c, et le petit deux en l’air, je n’en sais pas des masses plus).

Après une comparaison aussi pertinente, négocions le virage pour revenir au milieu du chemin (encore trois métaphores de ce type et je suis le nouveau Heidegger).
On pourra aligner les « définitions » qui circulent ça et là ( « site de mini-messages », « service de micro-blogging »…), on n’aura éclairé personne qui ne sait déjà ce que c’est. Et c’est un premier indice de la spécificité de ce qu’on appellera la chose Twitter : il est d’une part impossible de la définir entre trois mots, et pire, il est d’autre part quasi-impossible d’expliquer « à quoi ça sert » à quelqu’un qui ne connait pas, qui n’a pas fait son expérience de Twitter.

C’est là le drame. Et en même temps le sublime (mais oui, rien que ça — si vous pratiquez un peu ce blog, vous aurez pu remarquer que je n’ai pas peur d’élever le débat comme on élève son verre, ou pas loin). Allez, lâchons les chiens de la formule qui tue :

Expliquer Twitter à quelqu’un qui ne l’a jamais utilisé, c’est comme expliquer les couleurs à un aveugle.

On pourrait, on devrait, même aller plus loin : non seulement il faut l’avoir déjà utilisé, mais il faut être rentré dedans, comme on rentre dans un livre un peu rebutant. Ça prend du temps, et la probabilité qu’on abandonne dans les premières heures ou les premiers jours est très élevée.
Dans le cas de Twitter, le « verdict » est au choix : « Twitter, c’est nul, c’est juste MSN en moins bien »,  « Twitter, c’est chiant, c’est pas ça qui va me faire quitter Facebook », ou autre « Dans Twitter c’est vraiment débile cette limitation à 140 caractères ».

Twitter, ça ne sert à rien

Tiens, parlons-en, des 140 caractères. L’explication historique, pour ceux qui auraient dormi ces trois dernières années, est que l’une des premières contraintes auto-imposée par les créateurs de Twitter était d’envoyer et de recevoir les messages, les tweets, aussi par SMS. D’ailleurs ça a marché partiellement au départ en france, en 2007 et jusque début 2008 et votre serviteur s’était pas mal amusé à bricoler quelques bots psychopathes qui pouvaient lui envoyer des SMS intéressants, notamment sur l’état du trafic RATP. Mais c’est un autre sujet.
Ces considérations autobiographiques de haute volée mises à part, je vois mal qui aurait en 2006 parié trois carambars sur l’avenir d’un service Internet contraignant ses utilisateurs à « s’exprimer » avec une limitation de caractères, qui plus est assez vite atteinte. A l’heure où le bit se négocie au milliard de kilos comme un vulgaire poste à l’EPAD, quelle hérésie… Eh bien non seulement ça a marché, mais ça a permis de montrer, s’il en était besoin, qu’abondance de caractères nuit parfois, et qu’au fond, si on a quelque chose à dire, on peut toujours le dire plus simplement. Ou sinon, c’est qu’on se trompe de medium.

Cette contrainte génétique est une chose ; elle n’explique pas pour autant en quoi définir Twitter est un exercice particulier, ni en quoi comprendre et surtout expérimenter l’intérêt de Twitter prend du temps.
La raison principale est simple : Twitter, en tant que tel, ça ne fait rien. Même si on peut accéder en pur spectateur à une partie des « messages » mondiaux, le cœur de Twitter n’est pas un site mais un service (au sens informatique), dont le rôle se borne, pour résumer, à permettre aux gens de s’inscrire, de poster des messages ou tweets, de « suivre » d’autres utilisateurs et d’être suivis (l’un ne nécessitant pas l’autre), le principe étant de regrouper et de visualiser en un seul « fil de message » tous les tweets des utilisateurs qu’on suit.
Comme ça, je vous l’accorde, ça a l’air et trivial et pas très intéressant.
C’est parce que tout reste à faire : une fois inscrit, il faut suivre des utilisateurs (un certain nombre d’entre eux vous suivra en retour, surtout si vous commencez à poster des messages). Lesquels ? Ben justement, tout est là : ça dépend de ce que vous recherchez. La difficulté étant que d’une part rien n’oblige à savoir exactement ce qu’on cherche (bah oué, c’est la vie, quoi), et que d’autre part, on peut chercher plusieurs sortes de choses.

Twitter, ça sert à tout

Voilà l’essence de la chose Twitter, qui traduit la difficulté qu’on aura toujours à l’expliquer : Twitter, ça sert à ce qu’on en fait. Encore faut-il donc s’y mettre activement, définir et inventer ses usages — qui peuvent être mêlés, et changer au fil du temps, ce qui concourt à la complexité de compréhension de la bête. Utiliser passivement Twitter, c’est vraiment s’embêter avec un remplaçant de lecteur de flux RSS peu performant .

Twitter, ça peut servir, dans l’ordre et le désordre, de manière absolument pas exclusive et parfois complémentaire, à :

• faire de la veille, en suivant des gens qui postent beaucoup de liens, et/ou des flux RSS repostés
• discuter de manière plus ou moins impromptue et décousue avec des gens qu’on connait
• discuter de manière plus ou moins impromptue avec des gens qu’on ne connait pas, voire les rencontrer ensuite dans la vraie vie
• raconter sa vie, qu’il s’agisse de détails insignifiants ou d’épisodes cruciaux
• promouvoir des choses qu’on aime, des sites intéressants, des services et pourquoi pas des choses qu’on vend
• taper sur des choses qu’on n’aime pas, râler sur la RATP ou la SNCF
• faire des recherches sur ce qui se dit sur tous les sujets imaginables
• suivre en direct des émissions de télé palpitantes (ou du moins les commentaires avisés qu’en font les partisans ou les détracteurs)
• participer à des sortes de cadavres exquis ou le multilinguisme le dispute à la variété des sujets
• jouer au kamoulox
• savoir quel temps il fait à Dunkerque ou New-York…

Et ce qui est vraiment très bien, et intellectuellement excitant, c’est que ça peut être tout ça, un peu de ça, d’autre chose, dépendre des jours, dépendre du vent, de votre humeur et de ce qui se passe dans le monde. Bien sûr, cet aspect polymorphe demande une certaine disponibilité, en termes de temps et de présence d’esprit au sens strict.
Il y a peu d’intérêt à venir sur Twitter (quelle que soit la façon dont on consulte son flux) une fois par mois, tout se passe vite, parfois dans l’immédiateté et la fugacité, ce qui n’équivaut pas nécessairement à de l’inutilité.
Mais on peut aussi laisser filer un, deux, dix jours, et revenir comme un fleur sans que ça soit rédhibitoire ; ça n’est ni un blog, ni un forum, ni irc, ni msn, ni facebook, ni la pierre philosophale, et pourtant éventuellement un peu de tout ça en même temps.

En résumé, Twitter, comme Internet à sa façon, ne peut être défini et surtout expliqué en une phrase, parce qu’il y a autant d’usages de Twitter que d’utilisateurs.

Le nerf de la guerre, c’est le choix des gens qu’on va suivre ; une bonne méthode, c’est d’y aller à la pelle au départ, de regarder qui suit qui, qui « répond » à qui (avec le signe magique @), et de désuivre rapidement, surtout dans les premières semaines. Comme pas mal de choses, la suite se fait… en se faisant, et le résultat ne sera pas forcément celui qu’on avait prévu.
En tout cas, pour peu qu’on fasse quelques efforts (mais c’est peut-être là une exigence trop forte), l’inhabituel et la surprise sont vite au rendez-vous ; le banal et le quotidien aussi, mais il ne faudrait pas non plus demander à la réalité d’être immédiatement plus géniale que les gens qui la font. Et rien n’oblige personne à utiliser Twitter, encore moins à suivre des utilisateurs prétentieux ou analphabètes (et je vous le donne en mille : ça fourmille).

Une autre fois, on détaillera peut-être les us et coutumes qui régissent plus ou moins la twittosphère, comme on dit.

______________________________________

Si le sujet vous intéresse, il continue ici : Twitter est-il pour tout le monde ?
______________________________________

Je suis né l’année que l’on désigne comme celle du début de la micro-informatique, en raison de la commercialisation du premier micro-ordinateur, le Micral , machine vendue toute assemblée et basée sur le micro-processeur 8008 d’Intel. Mais malgré cet augure, et quoique j’aimerais bien me la raconter en clamant que j’ai touché un clavier avant de savoir marcher, mes premiers contacts avec les ordinateurs n’ont eu lieu qu’une dizaine d’années plus tard.

Sans bien savoir pourquoi exactement, je me souviens avoir à l’époque souvent rêvé d’Alice. Nan, pas la blonde transparente qui accourt quand on fait « ouh ouh ». Alice, un superbe ordinateur 8 bits à 1 Mhz, tout rouge, avec 4 Ko de RAM, dont les boîtes et manuels étaient ornés de dessins de Moëbius, rien que ça.
Malgré ces premières geekeries oniriques, ça n’est pas un produit Matra-Hachette qui m’a initié à l’informatique mais le clavier QWERTYUIOP grisâtre d’un Amstrad CPC 6128, au moment où par ailleurs (bien sûr je l’ignorais) Microsoft sortait la version 1.0 d’un certain OS à fenêtres.
Le CPC 6128, son Basic intégré de chez Locomotive Software avec les dollars après les noms de variable, l’éditeur ligne à ligne, les listings de programmes d’Amstrad Magazine tapés au mépris de mon avenir oculaire et, entre autres, Macadam Bumper et Jet Set Willy. Comme Boulet, on avait avec mes frangins fait une carte détaillée de toutes les pièces, mais on n’a jamais réussi à ramasser suffisamment de verres pour ne pas nous faire rembarrer par Maria . Saleté.
Côté programmation, mon premier chef-d’œuvre a dû ressembler à un truc comme ça :

10 CLS:MODE 1
20 INPUT "QUEL EST TON NOM :",A$
30 CLS
40 PRINT "BONJOUR ",A$
50 END

Ça s’améliora au fil des mois, bien sûr, et le Turbo Pascal succéda au Basic. Maintenant que j’y pense, j’avais aussi écrit en Basic un programme de boîtes aux lettres (à la mode Minitel, on disait « BAL », pas encore « mail »), qui permettait de créer un compte et d’envoyer des messages à d’autres utilisateurs. Messages sauvegardés sur une disquette 3 pouces double face de 178 Ko, of course. Bé ouaip.
Torride… à condition d’avoir la bonne disquette sous le coude, évidemment. Les RFC 821 et 1939 m’auraient été d’un grand secours mais, comment dire, on n’avait pas encore internet à la maison. Et pour cause. Le web n’existait même pas, ou était tout juste en train d’être conçu par Caillau et Berners-Lee.

Fin 80-début 90, donc, bien qu’en section littéraire, j’avais pris l’option informatique au lycée. On travaillait sur des PC sous DOS – probablement la version 4 – avec des disquettes 5 pouces 1/4, et c’était encore du Turbo Pascal. Évidemment, toujours pas d’internet ou de web, il faudra attendre encore quelques années pour que ça arrive en France. Pas de Windows non plus, la version 3.1 sortira l’année suivant mon Bac, et je ne la découvrirai que lorsque j’aurai à saisir mon mémoire de maîtrise sous Word 6 (livré sur sa demi-douzaine de disquettes).
On est alors en 1995, et le PC 486SX2 de mes parents (la dernière génération avant le Pentium) surmonté de son écran 14 pouces encaisse surtout des heures de Démineur. Mais c’est quand même sur ce clavier que j’apprends à me défaire des habitudes du QWERTY et à taper à plus de trois doigts, grâce à Dactylogiciel 3 de chez Micro Application (mais si, ça marche).
A l’époque, j’ai un peu laissé tomber la programmation. Si j’ai bien abordé le Prolog en Licence de Logique, ça n’a pas dépassé les salles de cours et les carnets de notes. L’arrivée de la première connexion internet changerera la donne.

…Tou bi continioude (suspens insoutenable)

Dans le prochain épisode, on découvrira comment avec une applet java et 100Ko de javascript on peut en 1998 écrire un crawler utilisé pour faire de la recherche full-text dans les pages HTML d’un site…

Une fois n’est pas coutume, on ne parlera ici ni de frèmeouorque, ni de design pattern, ni de champ lexical. L’un de mes nombreux vices, au-delà de la bière, des tournures improbables et de l’affèterie syntaxique, consiste en un rapport viscéral avec musique.

Pas uniquement classique, mais pour aujourd’hui, ça sera le sujet — encore que je doute de parler d’électro ou de minimale allemande sur ces pages un jour, mais bon, on ne sait jamais.

Comme j’aime bien aussi, outre l’affèterie, les sentences définitives, voilà ce par quoi je vais commencer : dans l’histoire de la musique classique (rien que ça), il y a trois gars qui font l’entrée, le plat de résistance et le dessert, ce sont respectivement Bach, Mozart, et Mahler. La métaphore culinaire étant un peu molle comme de la gelée, disons plutôt qu’ils font l’aube, la journée et le crépuscule — tout de suite ça claque bien mieux.

Je ne vous ferai pas aujourd’hui de chapitre sur Bach ou Mozart, ce que vous aurez compris vu le titre. Disons pour faire extrêmement atrocement schématique que le premier est la charnière entre le baroque et le classique, qui s’articule d’un point de vue (un poil) technique autour de l’avènement du tempérament égal, que le second déploie en réalisant la synthèse du galant et du savant, comme on dit — synthèse qui, comme de juste en dialectique, dépasse les deux. Et puis bien sûr, pour parler quand même d’un épisode interne pas inintéressant, il y a Beethoven, qui en torturant maladroitement un style assez héroïque, nettoie la place pour le romantisme qu’il porte un peu comme un alien en lui (je suis content de pas être prof de musico, soudain). Ainsi que d’autres grands malades au XIXème siècle, malheureux (Schubert), fous (Schumman) ou mégalos (Wagner), qui entament une réelle sape de l’édifice classique.

Et au bout de tout ça il y a Gustav Mahler. Pour tenter une analogie qui ne jettera pas forcément beaucoup plus de clarté mais que j’aime bien, disons que Mahler est à la musique classique ce qu’Heidegger est à la philosophie moderne : une déconstruction par l’intérieur après laquelle, du point de vue historique, il faut faire autre chose.

La fin de la musique

Bien sûr, l’Histoire ça ne marche pas comme ça, et il y a toujours des gens qui continuent à faire de la philosophie comme du temps de Descartes ou Spinoza (en pire, par exemple des individus dont le nom commence par Comte et se termine par Sponville).
De même il y a toujours des gens qui continuent à faire de la musique comme du temps de Mozart (en pire, par exemple des individus dont le nom commence par André et se termine par Rieu), comme il y a et y aura toujours des peintres du dimanche faisant des natures mortes ou immortalisant leurs chatons.
Qui plus est, les « tournants » de l’Histoire dont je parle ne sont en fait pas des moments univoques et homogènes, et ils engendrent des conséquences multiples et sèment dans différentes directions. Il serait assez naïf de dire qu’après Heidegger il n’y a plus de problème de l’être, ou qu’après Mahler il n’y a plus de tonalité.

Toujours est-il que Mahler est l’aboutissement de la musique classique, autrement dit ce en quoi il fallait qu’elle se résolve, et en quoi elle dit son dernier mot. Au sens hégélien, c’est la fin (la finalité, quoi) de l’Histoire.
Symptomatique en est le fait d’une musique quasi-exclusivement destinée à l’orchestre accompagné de voix, dans une tension vers une formation épuisant l’intégralité des instruments possibles.
Symptomatique également sa première conséquence, l’utilisation de la symphonie, genre englobant dont la forme se disloque (le nombre de mouvements montant jusqu’à 6) et le format explose (jusqu’à 200 musiciens)…

Mais Mahler n’est pas un simple Berlioz, et le gigantisme finit par être anecdotique, spécialement dans les dernières œuvres. Sans faire d’exégèse détaillée, on ne peut nier un côté souvent excessif, très beethovénien ou wagnérien, dans la première moitié des symphonies (et la huitième bien entendu). On comprend sans mal l’accueil fait par nos délicates oreilles françaises au début du XXème siècle, et le jugement sans appel de Debussy sur la 2ème symphonie ( « Le goût français n’admettra jamais ces géants pneumatiques à d’autre honneur que de servir de réclame à Bibendum » ).
Le jeune Mahler, qui comme tout le monde est aussi le fils de son temps, commence par tomber dans la prétention post-romantique de la musique à programme. Mais plus il réalise son acte, i.e. plus il avance dans son exécution (pas plus il en prend conscience, car il en prend forcément peu conscience), plus tous les éléments de la déconstruction s’affinent et se solidifient.

L’implosion de la mélodie et de la tonalité

En premier lieu, un coup porté à la mélodie, qui achève — au sens où on achève un mourant — le mouvement lancé par Mozart. Plus rien de galant dans ces thèmes à plusieurs têtes, ces intervalles qui dépassent l’octave, ces brusques sauts harmoniques à répétition. Et pourtant, l’ensemble est toujours fluide, l’orchestration rééquilibrant systématiquement les cassures.

On a dit ça et là que Mahler est le premier compositeur de musique de film.  Si ça n’est pas forcément pour lui faire un compliment, et si on n’a pas à l’esprit que l’Adagietto de la 5ème utilisé par Visconti, il faut reconnaître qu’il utilise l’orchestre sur un mode pictural où les thèmes sont le plus souvent partagés et noyés dans plusieurs couches de la formation : soit dans un océan de cordes, soit dans une foule hétérogène qui fait plus penser à un marché populaire qu’à un parterre d’opéra. Et c’est aussi une dimension de la transformation de la mélodie, qui quitte parfois complètement la ligne claire d’un ou plusieurs instruments pour se trouver dans la respiration macroscopique de plusieurs minutes d’affilée où l’on ne trouve parfois que quelques notes.

La fin de la 9ème symphonie en est l’illustration parfaite :

Jugez donc. Une fin qui dure plus de quatre minutes au bas mot (les deux dernières lignes insérées ici en prennent presque deux). Un decrescendo qui emmène jusqu’à pianissississimo (quatre p, quoi), où seules les cordes échangent, de manière de plus en plus espacée, quatre notes (fa, sol, la bémol, si bémol). La respiration ralentit. Il ne reste plus qu’un fa en suspension.

Et une seule indication, « Ersterbend » : « En mourant ». Difficile de symboliser plus littéralement la fin de la musique classique, même si le final du Chant de la Terre peut également être vu comme jouant ce rôle, pour d’autres raisons, à commencer par les paroles.

En second lieu, l’un n’allant pas sans l’autre, on assiste chez Mahler à l’érosion de la tonalité. Dès ses premières œuvres, les dissonances s’installent et ne sont pas résolues ou filent vers une autre dissonance, et la tonalité au sens où on l’entend dans la musique classique s’estompe. Non qu’il soit le premier, du simple point de vue de la datation, à changer fréquemment de tonalité ou à flirter avec l’atonalité (car on peut déjà se référer à Lizst), il n’est peut-être même pas celui qui va le plus loin, mais ainsi va l’Histoire.
Il met en revanche sur partition exactement l’expression de la façon dont le classique épuise ses possibilités modales et doit se transformer en autre chose, avec une nécessité qui exsude à chaque mesure, à la fois trop à l’étroit donc poussant vers une mue, et dans le même temps exactement à l’aise et à sa place, dans une sorte de réconciliation des tensions, comme après une bataille psychique qui serait enfin terminée.

Osons une (superbe) formule : Mahler, c’est Beethoven après thérapie. Plus besoin de taper 30 fois dominante/tonique en fin de mouvement (ok, Mahler fait ça aussi dans la 3ème, qui n’est pas la plus fine). Plus besoin de se référer à une tonalité ou à ses relatives, elles sont toutes là. Pour en revenir à la 9ème, notons qu’elle commence en ré majeur, et finit en ré bémol majeur, dans une sorte de glissement de terrain imperceptible qui transforme la couleur d’ensemble.
Mais à la différence de ce qui deviendra l’atonalité en tant que telle, Mahler reste un tonal. S’il dissout et nie en un sens la tonalité, il ne l’oublie pas. Négation ne signifie pas absence — car il faut bien quelque chose à nier…
Le pas suivant de l’Histoire de la musique est donc en toute logique l’assomption de cette absence (par Schönberg et Berg, entre autres), de ce vidage de la tonalité, longuement écopée par Mahler. On rentre alors dans la musique « moderne », le stade classique a touché son but et fini son déploiement.

En d’autres termes, la musique de Mahler conclut le classique. Mais cette conclusion porte en elle les retournements et les suites possibles. Pas étonnant de la part de quelqu’un qui disait « la tradition c’est de la paresse ou de la négligence », même si finalement c’est la destination de la tradition de s’annuler elle-même et d’engendrer des nouvelles traditions. En quoi la paresse n’est pas de connaître ou de suivre la tradition, mais de le faire sans le savoir et de s’y tenir. Évidemment, encore faut-il avoir quelque chose à dire.

Au risque de me répéter, en ce qui concerne la 9ème, la version de Boulez (avec l’orchestre symphonique de San Fransisco, 1998, Deutsche Grammophon) est exceptionnellement juste, je vous la recommande chaudement. Celle de Bernstein (chez Deutsche Gramophon également, mais attention, l’enregistrement avec le philarmonique de New-York, pas celui de Berlin) ne démérite pas non plus. Evitez Abaddo, il est très bien sur les opéras de Mozart, beaucoup moins bien avec Mahler.

Pour une fois, le champ lexical auquel le concept est emprunté n’est pas celui du BTP, même si on n’en est pas loin : c’est celui de l’électricité. Découpler y signifie supprimer le couplage entre deux circuits (ok, on est proche de la lapalissade, mais bon).

L’exemple le plus parlant sera celui de la prise électrique. Si on n’avait pas défini de standard ni  un principe de prises mâles et femelles, on vivrait dans un monde où les appareils électriques ne pourraient être vendus prêts à être branchés, où il faudrait  faire intervenir un électricien pour les raccorder au réseau, et où une fois installés on ne pourrait plus les déplacer ni les brancher ailleurs (sauf à répéter l’intervention). Assombrissons le tableau, et imaginons que dans ce même monde le réseau électrique n’aie pas de tension standard, mais distribue du 230 volts ici, 110 là, 3.14 ailleurs, etc. Non seulement il faudrait une manipulation technique pour connecter le grille-pain, mais aussi pour l’adapter à la tension. Manip’ à répéter à chaque déplacement de la bête…

Le problème que l’on aurait dans un tel monde serait celui d’un très fort couplage entre les appareils et le réseau électrique. Inutile de vous faire un dessin pour expliquer à quel point ça ne serait pas commode. Pour rester poli et ne pas dire chiant. Ah mince je l’ai dit.

En informatique, on s’est rapidement soucié du couplage, que ce soit du point de vue matériel comme pour les prises électriques en définissant des standards plus ou moins universels (PCI, RS232, USB, firewire…), ou logiciel (dans les programmes, ou dans les couches inférieures, par exemple le modèle adopté pour l’interconnexion des réseaux, OSI, mais c’est un autre sujet).

En ce qui concerne le sujet qui nous intéresse, le développement d’applications web via les frameworks en général et Symfony en particulier, le découplage est une notion critique.
Elle fonde l’organisation du framework lui-même, et sous-tend toutes les bonnes pratiques qui vont avec et doivent être appliquées dans le code spécifique à l’application.

Interfacer pour mieux découpler

Pour le formuler autrement, le découplage consiste en l’indépendance maximale de toutes les « briques » entre elles. Mais comme ces briques doivent communiquer, leurs interfaces, c’est-à-dire leur frontières de communication, doivent être codifiées.
C’est pourquoi en électricité on a réduit les nombres de connecteurs et définit des standards. C’est pourquoi en informatique on a défini des protocoles, autrement dit des règles d’échange. Car pour permettre le découplage, il faut se concentrer sur l’endroit — si je puis me permettre — où ça s’accouple, et l’abstraire des contingences et des spécificités (amen).

De la même manière qu’on ne souhaite pas avoir à changer de grille-pain si on change les prises ou si on déménage, on veut pouvoir faire abstraction, en développant une application web, de la façon dont l’accès aux données est géré (il nous suffit de savoir qu’il l’est), du type de serveur de base de données (on veut idéalement pouvoir utiliser n’importe lequel). Bref, on veut pouvoir se brancher dessus sans avoir à se demander comment. Aussi simplement qu’en branchant une prise mâle dans une prise femelle.
D’une manière générale, les fonctionnalités du framework doivent pouvoir être utilisées les unes indépendamment des autres, sans quoi leur mise en œuvre reviendra la plupart du temps à écraser une mouche avec un marteau-piqueur, ou pour rester sur notre champ lexical du jour, à faire construire une maison entière pour pouvoir brancher notre grille-pain.

Cette indépendance des « éléments » a un deuxième intérêt, non des moindres : il rend possible l’évolution ou la réparation des uns sans avoir à intervenir sur les autres.
Dans la vie bien découplée, vous pouvez acheter une cafetière neuve (ouaip, changeons d’objet électroménager, ça commence à devenir saoulant le grille-pain) sans avoir à refaire toute votre installation électrique, non ? Et bien si votre code et votre application sont eux aussi correctement découplés vous devez pouvoir modifier, mettons, votre logiciel d’envoi de mail sans avoir à retoucher à tous les endroits où vous envoyez des mails.

En résumé, si vous voulez briller en société (ou en lan party, encore que..) pensez à caser « découplage » au détour d’une saillie, ça fait toujours son effet. Si vous voulez briller en tests unitaires, c’est bien aussi, mais ça sera l’objet d’un épisode de la saison 2.

Dans le prochain épisode, cette fois c’est juré-craché-si-je-mens-je-vais-à-Denfert, on parlera de MVC…

« IL », c’est l’ordinateur, bien sûr. Tentative ultime de raccrocher à une figure un peu anthropomorphisée ce qui se passe en fait dans la machine, autrement dit les programmes qui font des machins. Parce qu’évidemment, tout le monde le sait, l’ordinateur ne fait rien lui-même. Il n’est ni intelligent, ni bête, il fait ce pour quoi on l’a programmé.

Alors pourquoi, pourquoi cette impression si facilement partagée qu’il y a quand même là-dedans une sorte de volonté propre, ou pire, aléatoire (ou encore pire quand vraiment tout va mal, machiavélique)..?

Passons sur notre tendance à l’anthropomorphisme, assez récurrente, réflexe ancestral face à l’inconnu et l’incompris. S’il n’y avait que ça, il suffirait de se moquer et ça serait plié. Non non non. Il y a forcément plus.

Ce qu’il y a, c’est que les programmes qu’on utilise ont depuis longtemps dépassé le stade des micro-routines. Ils représentent parfois des millions de ligne de code, et même s’ils ont été élaborés en suivant les règles de l’art (respect des bonnes pratiques, design patterns, pizza, versionning des sources, etc), leur niveau de complexité excède grandement nos capacités d’appréhension en un seul coup d’œil, pour le dire comme ça.
En d’autres termes, ils ont franchi le seuil au-delà duquel il n’est plus possible pour quiconque de savoir ce qui va exactement se passer dans tous les cas possibles (notamment parce que ces « cas » sont trop nombreux, donc qu’on peut difficilement assurer qu’on les a tous envisagés).

Si on veut recourir à une analogie (tu es nouveau ? Cliquette ici), disons que tout programme dépasse rapidement le stade où on peut croire qu’il est un ensemble fini prévisible, pour devenir un système probabiliste gazeux.

La principale conséquence en est que l’utilisateur (et même le créateur) n’est jamais complètement certain de ce qu’il va faire. Et de quoi est-ce que c’est la caractéristique, au fond, je vous le donne en mille ? De l’altérité.

L’autre. Ce truc qui n’agit pas comme dans ma tête. Bref, sans imaginer bien sûr qu’il ait une volonté propre, le programme a suffisamment d’ « indépendance » pour se comporter comme quelque chose d’aussi imprévisible qu’un être humain, et c’est assez génial (en tout cas à titre personnel je trouve ça exaltant, mais les clients ne partagent pas toujours cet avis, bizarre…)

D’où cette belle formule, qui me sert à briller à la cafeteria ou à clore certains débats stériles : oui, les ordinateurs (en fait : les applications) sont des êtres humains comme les autres.

Et c’est pourquoi bien programmer passe principalement par l’application de bonnes pratiques qui visent à réduire au maximum les interstices où va se fourrer l’imprévisibilité, et à tester au maximum toutes les éventualités qui peuvent se présenter — ce d’autant plus que, en face de l’ordinateur, il y a un utilisateur, qui lui aussi est imprévisible, et qui comme vous l’aurez appris si vous développez, fera toujours exactement le truc que vous n’aviez pas prévu.

_________________________________

Illustration : Marvin le robot dépressif, dans H2G2 – The Hitchhiker’s Guide to the Galaxy

Là où je sévis actuellement, un document interne secret à visée caustique recense ces termes et d’autres ; la liste qui suit s’en inspire librement, avec d’autant moins de scrupules que je suis à l’origine des deux tiers d’entre eux.

- Levier : solution en général fictive mais rhétoriquement commode pour faire croire ou se persuader qu’on a des moyens d’action. Nous avons identifié les leviers à notre disposition pour raccourcir les délais.

- Paralléliser : recours ultime lors d’une négociation de planning, dont le but – fantasque – est de diviser linéairement les temps de production par le nombre de ressources affectées. Voir le post consacré au sujet.

- Pragmatique (ou sa variante réaliste) : attitude consistant à sacrifier la qualité tout en se défendant de le faire.

- Proactivité : technique de management pragmatique consistant à demander au collaborateur de résoudre les problèmes à venir sans les connaître à l’avance.

- Proposition (force de) : Nous attendons que vous soyez force de proposition. Façon aimable qu’a le client de demander au prestataire de faire son travail à sa place.

- Temporiser : pour le client, indique qu’il n’a pas encore pris le temps de trancher les choses dont vous avez absolument besoin pour avancer sur un livrable qu’il exige pour demain. Pour le prestataire, signifie que les développements qui devaient commencer hier avec trois ressources commenceront la semaine prochaine avec une demie. Doit toujours cependant être utilisé dans une phrase qui laisse penser que tout cela est parfaitement volontaire. Nous avons décidé de temporiser.

- Tiroir : dans la vraie vie, élément coulissant d’un meuble ; dans une proposition commerciale, élément coulissant du devis exigé par le client pour se donner les moyen de faire baisser le montant total. Pouvez-vous me faire une proposition à tiroirs ? Attention : dans la pratique, le client choisit toujours de conserver des tiroirs qui ne peuvent être réalisés sans ceux qu’il a retirés.

- Transverse : notion à utiliser en biais ; bien commode pour camoufler son ignorance du contenu exact d’une intervention. Nous avons mobilisé des compétences transverses.

- Valeur ajoutée : concept à utiliser sans parcimonie dans tout discours de vérité (voir ci-dessous). Cette fonctionnalité n’a pas de valeur ajoutée.

- Vérité (discours de) : stratagème circonlocutif, destiné à obscurcir le sens de ce qui est dit sous couvert de transparence (on dit également : « enfumer »). Fonctionne également comme prétérition, pour tenter de rester poli : je vais te tenir un discours de vérité, ton code c’est vraiment de la merde.

Bien entendu, toute ressemblance avec des phrases ayant été prononcées dans la vraie vie serait étonnamment fortuite, etc, pardon aux familles tout ça.

__________________________

Superbes illustrations trouvées fortuitement chez Getty Images.

Résumé de l’épisode précédent : un framework, c’est une boîte à outils, des briques de base, et une méthodologie pour développer mieux, plus vite, et de manière plus sûre (un peu comme ça, quoi). Mais si ça peut fortement aider, ça n’est pas magique, et ça demande de suivre les principes du framework lui-même.

Une partie des principes méthodologiques qui va avec un framework est  couramment regroupée sous le nom de design patterns. Une fois encore, on s’abstiendra de traduire l’expression (la version française préconisée étant patrons de conception, et ça sonne un peu Bergère de France…)

Pour faire court (dans un premier temps), disons qu’un design pattern est une façon de résoudre un problème type. Il ne s’agit donc pas d’une solution en tant que telle, mais plutôt d’une recette, c’est-à-dire la description d’une manière d’opérer face à un certain type de problème.

Historiquement, la théorisation des design patterns fait beaucoup référence, et c’est une chose qui ne nous étonnera pas, au domaine de l’architecture, de l’urbanisme et de la construction, notamment suite au travaux de Christopher Alexander dans les années 70.
Constatant que la conception en architecture en particulier, mais aussi en ingénierie en général, conduisait à affronter des problèmes récurrents (isolation, solidité des structures, communication entre l’intérieur et l’extérieur…) il abstrait des archétypes destinés à couvrir tous ces aspects.

Un pattern est ainsi à comprendre comme un « modèle » éprouvé reliant une solution à un problème dans un certain contexte.

Tout problème de conception, dirait Alexander, met en jeu un seul individu face à une immensité. Ce problème contient un certain nombre de variables qui, combinées en sous-ensembles, représentent un nombre de cas débordant rapidement les capacités limitées de son cerveau.
D’où l’intérêt de diviser et de hiérarchiser ces sous-ensembles pour les étudier à part, et recourir à ce qu’on pourrait nommer le bon sens collectif de l’histoire (capitaliser sur les solutions qui ont prouvé qu’elles marchaient).
Dès ses premiers travaux Alexander met l’accent sur la nécessité de comprendre les rapports entre les parties et le tout, et de savoir comment s’y prendre pour traiter ce tout. Ce que nous avons appelé dans l’épisode précédent faire face à la complexité.

De l’urbanisme à la POO

En 1995, les quatre mousquetaires du pattern, le bien nommé « Gang Of Four », s’inspirent d’une partie de ces travaux et transposent la méthode dans la programmation orientée objet. Comme Alexander, même si la démarche est, disons, moins empreinte d’une sourde angoisse métaphysique quant à l’appréhension de l’infini, leur but est de proposer des outils conceptuels pour gérer la complexité, en l’occurrence, posée par certains problèmes récurrents en programmation.
Ils sont issus des bonnes trouvailles et des bonnes pratiques de générations de développeurs et dispensent ainsi, comme on dit souvent, de réinventer le fil à couper la roue.

J’avais commencé un paragraphe complet donnant un exemple (en choisissant le pattern bridge, un modèle assez « simple »), et j’ai renoncé, car on ne peut pas en dire grand chose sans évoquer la programmation orientée objet, que ma chère maman n’est pas censée connaître, donc qui déborde le cadre de cette page.
Je tâcherai de présenter en revanche dans un épisode prochain le MVC, un design pattern assez connu — qui est en fait, pour être rigoureux, une combinaison de patterns. Retenons juste ceci en attendant, et au risque de me répéter : il ne s’agit pas de classes ou de bouts de programme, mais de façons de structurer son modèle de données, son architecture, son application, et ultimement son code (quelque soit le langage objet).

En guise de conclusion, et pour s’éloigner définitivement d’Alexander, signalons qu’on parle aussi de temps en temps du négatif des patterns, les antipatterns.

Comme leur nom l’indique, il s’agit des façons de faire qui sont exactement ce qu’il faut éviter. On regroupe sous ce nom des pratiques hétérogènes aux noms parfois sympatoches, comme la coulée de lave (mise en production d’un code non stabilisé qui de fait devient de moins en moins modifiable, se « solidifiant » comme de la lave), l’ancre de bateau (code conservé pour des raisons « politiques », pour ne pas fâcher un développeur et/ou en se disant qu’il servira plus tard…), ou l’objet divin (méthode ou fonction servant à trop de choses, et dont on finit par ne plus trop savoir comment elle marche).
Elles sont évidemment, presque autant que les autres, utiles au développeur — qui aura toujours au début de son existence mis en œuvre, même à son corps défendant, au moins l’un d’eux, sinon presque tous.

Dans le prochain épisode, cette fois, on parlera de MVC…

___________________________________

Image du Schéma empruntée ici : http://www.simonwhatley.co.uk/coldfusion-and-design-patterns

Quand vous faites partie du second groupe, ou quand vous travaillez dans le développement d’applications, vous apprenez rapidement qu’il existe, au-delà de l’heure, du jour, de la semaine, une unité de mesure capitale : le jour-homme.

Je me dis depuis quelque temps qu’on pourrait même entériner un nouveau mot : le « jourhomme », que la réforme de l’ortografe transformerait en « jourome », et ça serait sympa. Sans parler bien sûr du jourfemme qui devra exister impérativement. Mais je m’égare.

Comme son nom l’indique presque, le jour-homme correspond au travail d’une personne pendant une journée. Ca fait beaucoup rire nos amis anglo-saxons de nous voir utiliser une telle mesure qui passe sous silence toute discussion éventuelle sur la valeur du référent… Il nous faut alors leur expliquer que par chez nous, la durée « officielle » d’une journée de travail est de 8 heures, même s’il s’agit en fait d’une durée admise comme standard – avec toutes les élasticités bien commodes que ça implique, et qui permettent de faire au besoin rentrer deux « jours » en une journée (ben oui, il suffit de travailler de 8h à minuit, fastoche).

Quand on estime une charge de travail, on la chiffre donc en jours-homme.
En général, on colle ça après dans un calendrier (avec ou sans l’aide de certains logiciels pas lourds du tout dont le nom commence par « pro » et se termine par « ject »), et ça nous donne un planning, autrement dit une représentation dans le temps de la vie des vraies gens, week-end et autres jours chômés inutiles pris en compte.
Il est étonnant de remarquer à quelle vitesse on finit à force de faire cet exercice par penser en multiples de 5, et par assimiler 1 mois au chiffre 20 (ce qui est par ailleurs souvent inexact, mais bon, à la louchasse, c’est ça). On met en général plus de temps à intégrer comme un réflexe le calcul inconscient de marges de sécurité conséquentes (de 20 à 50%).

Toujours est-il qu’à l’arrivée, on présente au client un planning, dans lequel il ne regarde en général qu’une seule date, celle de la livraison. C’est le moment où il fait des grands yeux, voire devient livide, voire s’énerve, voire tout ça en même temps ou dans un ordre aléatoire.

Mais, tenez-vous bien, ça n’est pas grave. Pourquoi ? Tout simplement parce qu’on va pouvoir optimiser le planning. Et c’est quoi la solution magique pour optimiser le planning ?

Oui, vous avez trouvé : la parallélisation.

La parallélisation, c’est cette bonne idée qui consiste à dire qu’on va mettre plusieurs gars sur le coup (ou filles, hein, enfin si seulement on en avait dans l’équipe de développement), et que paf par magie ça va linéairement diviser le temps de production par le nombre de ressources affectées. En gros (si vous êtes un peu malcomprenant), s’il y a 60 jours-homme, en mettant deux développeurs, ça va être fait en 30 jours.

Jusque là, je n’aurais presque rien à dire. C’est presque vrai, c’est même presque malin, voire presque réaliste. Sauf que vous connaissez les gens : il leur en faut toujours plus (les coquins). Donc vas-y que jte mets 4 développeurs et c’est torché fait en 15 jours ! Vous voyez venir l’écueil (enfin, j’espère, c’est pas faute d’être lourdement didactique) : tant qu’on y est, mettons 60 développeurs, et ce soir c’est plié.

Sans parler de l’incongruité en termes d’écosystème (essayez de regrouper 60 développeurs et vous comprendrez), on a évidemment oublié un détail dans cette équation, trois fois rien, un mot innocent : la ré-a-li-té.

Eh oui. Dans la réalité, répartir la charge induit très vite des « coûts » collatéraux, notamment en coordination du travail. S’il est souvent envisageable de séparer les tâches en plusieurs lots, il n’est pas dit qu’ils puissent être, d’un point de vue logique, tous réalisés en parallèle.

C’est chiant, la réalité, ça marche pas toujours comme les maths ; par exemple, un lapin plus un lapin, pour peu qu’ils soient de sexe différent, ça a vite des chances de faire plus de deux lapins. Vous me direz : ah mais il s’est passé quelque chose.  Mais justement, ce qui est caractéristique de la réalité, c’est qu’il s’y passe des choses, et qu’il y a des contraintes qu’on ne peut pas réduire, même si on est très bon en maths.

J’aime bien recourir à une image qui fait en général son petit effet. Elle n’est pas de moi, je crois l’avoir trouvée quelque part dans un machin imprimé, un livre, là, mais je ne retrouve pas la référence, et Google est curieusement un peu muet sur le sujet. En la sortant au bon moment, le résultat est garanti :

Si on met 9 femmes enceintes en parallèle, on n’aura pas un enfant en 1 mois.

Si vous faites bien vos devoirs, vous ne devez toutefois pas prendre cette superbe saillie pour argent comptant, et questionner l’analogie (n’est-ce pas). En d’autres termes, demander si développer une application, c’est comme faire un bébé (je vous passerai toutes les bonnes blagues auxquelles ça peut me faire penser, sinon on va y passer l’hiver).

Soyons prudent sans faire de la langue de bois : oui, il y a dans les processus de développement des étapes, qui ne peuvent que s’enchaîner et donc pas avoir lieu en même temps. Il faut pour cette raison ne pas hésiter à affirmer que :

• le temps nécessaire n’est pas linéairement divisible par le nombre de ressources affectées ;
• l’augmentation du nombre de ressources accroit de manière exponentielle les tâches de coordination, et tend pour cette raison très  rapidement à annuler le gain de temps nominal (voire à l’inverser, c’est-à-dire à faire perdre plus de temps qu’on en gagne).

Selon les métiers et les projets, le point de la courbe où la tendance s’inverse est plus ou moins vite atteint, mais d’expérience on constate qu’il l’est toujours plus vite que ce qui serait nécessaire pour satisfaire des plannings irréalistes. Et le plus difficile, c’est de le faire comprendre aux « décideurs » (car les coupables ne sont pas toujours les clients, si si…)

D’où les 9 femmes. Ça n’est pas magique, mais ça peut avoir son poids dans une argumentation.

Il aurait alors fallu agrandir légèrement l’objet, de 115 mm de diamètre aux 120 actuels. Mais comme au pays des légendes on ne peut jamais s’endormir tranquille après une bonne bière et une bonne histoire, une explication concurrente (probablement fantaisiste, n’ayons pas peur de le dire) voudrait que cette taille soit en fait celle des dessous de verre à bière standard des Pays-Bas.

Fantaisie ou pas, ça ne serait pas la première fois qu’un objet du quotidien sert de base arbitraire à une décision engageant ensuite tout un secteur.
Dans un genre proche des verres à bière, et probablement plus crédible, on raconte que les disquettes 5 pouces 1/4 (que certains, y compris moi, ont connu ; c’était il n’y a pas si longtemps encore, sales jeunes) devaient leur taille à un autre objet célèbre dans les bars et restaurants. Si si.

Voilà l’histoire : alors que les disquettes 8 pouces, le premier standard de l’histoire, commençaient à encombrer franchement les utilisateurs (20 centimètres de large, pas simple à ranger dans son sac à main, jvous raconte pas), les laboratoires Wang demandèrent à l’un des associés du créateur de ladite disquette de travailler à un modèle plus réduit.
Lui :  « quelle taille elle doit faire ? »
Eux :  (en montrant une serviette de table) « oh, genre ça ».
(Je sais, j’ai un grand talent de conteur).
Il n’en aurait pas fallu plus pour que les disquettes, pendant près de 20 ans, fassent 5 pouces 1/4 . La taille d’une serviette de table.
On raconte également que le successeur, la disquette 3 pouces 1/2, fut conçue de façon à tenir dans une poche de chemisette américaine standard. Je n’ose pas imaginer ce qu’on pourrait trouver comme légende pour l’invention de la clef USB… Rhem.

Ainsi en va-t-il souvent des spécifications (voix caverneuse). Il n’est pas toujours question de nombre d’or ou de grands desseins galactiques mais, comme dans les meilleures traditions de création littéraire, c’est souvent au bistrot que ça commence.
C’est souvent là que ça finit aussi, mais c’est une autre histoire.

Ce framework porte le nom de Symfony, pour des raisons expliquées ici. Jusque là, fastoche. C’est ensuite que ça se complique. Déjà, rien que le premier mot : framework. Littéralement, cadre ou structure ; dans la programmation en général, on le traduit plus précisément par « cadre d’applications ». Enfin, on le traduirait, parce qu’on ne le fait jamais, on dit toujours frèmeouorque. A compter de cette phrase, je dirai d’ailleurs « framework » sans autre forme de procès, et même sans italiques (je suis comme ça, jsuis un gueudin).

Pour commencer, donc, qu’est-ce qu’un framework ? S’il y avait une réponse simple, on se passerait de ces lignes. La difficulté majeure tient à ce qu’il y a en fait dans la définition deux dimensions principales, complémentaires mais en partie indépendantes : un framework c’est à la fois une boîte à outils et une méthodologie. Ou, si on n’a pas peur des envolées lyriques : une boîte à outils fournie avec une philosophie.

Une boîte à outils

On a l’habitude de comparer un framework à un ensemble des « briques » toutes faites qu’on peut utiliser pour son application .
Si l’analogie n’est pas trop mauvaise, elle est insuffisante, parce qu’un framework c’est plus que ça. Cela dit, l’image de « brique » convient assez bien à ce qui circule çà et là sous le nom de composants (et d’ailleurs, le monde est bien fait, car certaines parties de Symfony sont justement mises à disposition comme composants : http://components.symfony-project.org ; dingue, hein ?)

Mais revenons à l’analogie de départ, même si elle est un peu faible ; elle dit qu’un framework est à un développeur ce qu’une boîte à outils est à un bricoleur.

Sous plusieurs aspects, un framework peut effectivement fonctionner comme une boîte à outils, en ce sens qu’il propose, dans le cas de Symfony du moins, un certain nombre de trucs pour faciliter le travail, l’accélérer, voire automatiser tout ou partie des tâches qu’on rencontre lors du développement d’une application web. C’est le côté work du framework, si l’on veut.
Enfoncer un clou, à la main, c’est douloureux et très long ; avec une pierre, moins douloureux, mais pas très précis. Avec un marteau, l’outil est assez optimal – même s’il ne dispense toutefois pas de taper. En plus, ce marteau a été testé industriellement, donc a de bonnes garanties de solidité .

Dans le développement web, on ne plante pas des clous, mais il y a des tâches équivalentes qui sont répétitives, peu gratifiantes, et d’autant plus sujettes à erreur qu’elles sont répétitives et peu gratifiantes : construction de bases de données à partir de leur schéma, import de données de test, initialisation d’interfaces d’administration, exécution de tests, gestion du cache, des urls…

Pour tout ça, le framework offre marteaux et tournevis, voire dans certains cas pistolets à clous. Ces « utilitaires »,  testés et mis à l’épreuve du feu par de nombreux développeurs, ont bénéficié de leurs retours d’expérience, leur efficacité et stabilité sont assurées par ce processus. Mais pas plus qu’un marteau ils ne dispensent pas de taper. Vous pouvez vous procurer une belle boîte à outils, ça ne fixera pas pour autant vos étagères au mur …

A un niveau un peu plus complexe, le framework (du moins Symfony) favorise l’intégration en deux coups de cuiller à pot de plug-ins, qui sont un peu comme les briques évoquées plus haut. Il en existe un grand nombre, pour des fonctionnalités plus ou moins évoluées (authentification, gestion de médias, de contenu…). On dépasse là le cadre de la « boîte à outils », et on est plutôt sur des objets de base qui font gagner du temps. C’est comme acheter des planches déjà découpées plutôt que de les scier soi-même. Mais ces objets conviennent rarement tels quels . Il faut les adapter à ses besoins. Par exemple peindre ses planches de la couleur qui va bien, choisir combien on en pose, à quelle distance les unes des autres…

Point crucial : dans le cas du framework, l’adaptation sera grandement facilitée par la méthodologie qui doit avoir été respectée par les créateurs des plug-ins. C’est-à-dire : si elle a été respectée.

Ce qui nous fait une transition toute trouvée pour le second aspect, non des moindres, de la définition d’un framework : en plus d’être une boîte à outils, un framework, c’est une façon de travailler.

Une méthodologie

Pour tenter une analogie, disons qu’un framework est à la programmation ce que grammaire et orthographe sont à la pensée.

On quitte là le champ lexical du bricolage pour celui de la linguistique, ou plutôt de l’apprentissage du langage . Glissement qui semble tout indiqué, puisqu’on parle de langage de programmation. Si on fouille un peu, on verra même que la nécessité de changer de champ répond en fait à une exigence interne, dictée par le caractère spécial des langages artificiels : un croisement génétique, pour ainsi dire, entre de la logique (qui se veut mécanique et déterministe) et de la pensée (qui reste inductive et poétique par nature, mais c’est une autre histoire).

Filons la métaphore. Quand on se met à programmer, on apprend une syntaxe, des fonctions, des mots-clés… ; bref, une sorte de grammaire et de dictionnaire .
Mais connaître par cœur l’intégral de la phpdoc ou autre n’a jamais fait un bon développeur, pas plus que réciter le Bescherelle n’a fait un grand auteur.

C’est là que, tel un cavalier qui surgit hors de la nuit (mince, ça y est maintenant j’ai la musique de Zorro dans la tête), intervient le framework. Il joue un rôle à la croisée de la rhétorique, de la littérature et de la logique :

• il énonce des conventions d’écriture et d’organisation destinées à rendre plus efficace, en homogénéisant et clarifiant
• il s’inspire des bonnes pratiques déjà existantes, notamment en termes de style
• il structure et favorise la discipline du code produit, et son indépendance à l’égard de toute solution logicielle ou matérielle.

En gros, il joue son rôle de « cadre » et de structure. C’est le côté frame du framework : il contraint à un certain nombre de choses, mais pour mieux libérer le processus intellectuel, en particulier en l’affranchissant des routines chronophages, et en aidant, par la clarté exigée, à faire face à l’augmentation de la complexité .

Si tout développeur qui connait un tant soit peu un langage (PHP en particulier, qui est plus facile d’accès que d’autres) est capable, même en tâtonnant, de mettre au point une application plus ou moins évoluée, l’expérience montre toutefois que son degré d’instabilité croît alors exponentiellement à la mesure de sa complexité, et que son code a tendance à devenir incompréhensible (et donc instable, indébuggable, non maintenable, etc…)

Pour faire face à la complexité, il faut être équipé de certains outils, intellectuels cette fois. Un framework a pour but de fournir de tels outils facilitant la modélisation des objets, de leurs relations, et des solutions aux problèmes posés. Il est à la fois une extension du vocabulaire du développeur et un perfectionnement de ses capacités grammaticales.
Du moins, il peut l’être. Car comme le marteau ne tape pas tout seul, le framework ne pense à la place de personne. Pire, comme un marteau, mal utilisé, il peut faire mal. Et s’il tend à structurer, il n’oblige ultimement personne à suivre sa méthodologie ; s’il peut aider à discipliner, il ne remplace pas l’auto-discipline qui est du ressort de ceux qui conçoivent et écrivent le code. Bref : un framework ça n’est pas la pierre philosophale qui changera votre code de plomb en or.

On se résume : côté pile, le framework est un cadre structurant, côté face, le framework est un outil facilitant le travail.
Finalement, on avait bien raison de garder le mot anglais.

Dans le prochain épisode, on parlera de design patterns…

Divers livres et endroits du web m’ont indiqué que cette tradition était typiquement française , je ne sais pas s’il y a de quoi s’en réjouir. Sans parler du fait que la distinction MOA/MOE, notamment, impose une séparation assez artificielle entre le métier (client) et la technique (prestataire), qui finit par opposer politiquement les savoir-faire plutôt que de viser à les faire se rencontrer, sans parler non plus du fait que si dans l’informatique ou les applications web tout se passait comme lors de la construction d’un bâtiment, on perdrait sans doute moins de cheveux , sans parler de tout ça donc, même si maintenant c’est un peu fait, je voudrais élever rediriger le débat (ben tiens) jusqu’à la question de l’opportunité et de la pertinence de certaines métaphores fréquemment utilisées dans notre beau métier (les applications web).

Sans grande surprise, quand quelqu’un dans ledit métier, client ou prestataire, se lance dans une métaphore filée , il puise dans le champ lexical du bâtiment. Déduction (maintenant possible) : il est français ; bon, en général, on le sait déjà.
De manière un peu plus surprenante, quand ça se produit, ne me demandez pas pourquoi mais neuf fois sur dix il ou elle prend l’exemple d’un carreleur. Celui qui pose le carrelage, quoi, vous savez le truc par terre, là. Pourquoi le carrelage ? No sé ; on demandera à Freud de se pencher sur la question. Bref.
La suite de l’histoire, car il s’agit toujours d’une histoire personnelle, se résume dans les grandes lignes à :

1. le carreleur a fait un devis précis sur le nombre de mètres carrés à couvrir, voire dans les meilleurs versions, sur le nombre carreaux
2. il l’a fait signer avec le sang et il a demandé un acompte
3. il a réalisé le travail, et toute demande supplémentaire a été facturée

Cette narration édifiante (rappelez-vous l’étymologie d’édifiant) se termine par une conclusion en forme d’exhortation : si un carreleur peut le faire, il n’y a pas de raison qu’on ne puisse pas y arriver également, et appliquer cette façon de travailler !

C’est là que je dis : attention, Maurice (mettons que la personne qui a raconté son histoire s’appelle Maurice). Les raisons, s’il s’agit d’en trouver, il peut y en avoir plein. Je dirais surtout trois choses :

1. Ça n’est pas parce qu’une histoire est imagée, avec un exemple de la vie quotidienne (comprenez : concret et qui va parler à tout le monde), moult détail et foult anecdote dont l’authenticité le dispute à la théâtralité, qu’elle impose nécessairement comme une conséquence irrévocable et pour ainsi dire congénitale sa vérité, et, encore moins, son caractère de preuve.
   Pour le dire avec moins de mots : fezez gaffe aux images ! Rien ne va de soi, et surtout pas le choix d’une analogie (le mot est lâché ). D’une manière générale, l’image a tendance à endormir l’intelligence, parce qu’elle s’impose aux yeux en un seul morceau .
2. Conséquence du point précédent : quand il y a une métaphore filée, questionnez l’analogie. Nétadire ? Nétadire qu’avant de prendre pour argent comptant la conclusion de Maurice, demandez-vous si la relation qui est établie entre, dans notre cas, le fait de poser des carrelages et celui de développer une application web, est effectivement pertinente. Les analogies, c’est bien, mais on n’est pas obligé d’être d’accord avec les choses qu’elles présupposent, par exemple que carreler c’est la même chose que faire un site web.
   Déjà, dans la réalité, je connais peu de clients qui demandent l’équivalent de « mettez-moi tel carrelage sur ces 12 mètres carrés » ; au quotidien, ça donne plutôt quelque chose comme « j’ai une pièce à refaire, je ne sais pas trop sa surface, mais il faut que ça soit moins salissant », suivi après livraison de « ah mais il allait de soi qu’il fallait aussi faire les murs, enfin ».
3. Ensuite, et c’est surtout ça le point important, faire une appli web, ça n’est pas poser du carrelage ; s’il fallait tenter d’induire quelque analogie dans le domaine du BTP, ça nous donnerait plutôt : « en général, faire une appli web, c’est comme construire une maison avec un nombre de pièces qui évolue en fonction des actions des habitants, dont la porte les reconnait et leur propose une salle à manger différente selon l’heure de la journée, avec des escaliers dont le design doit pouvoir être revu toutes les trois semaines sans empêcher les gens de les utiliser, un toit qui protège des intempéries existantes mais aussi non connues à ce jour, une pièce qui fait les déclarations de revenus, déclenche automatiquement le paiement des factures, engage ponctuellement du personnel de ménage… Tout ça avec une maison de backup qui chaque nuit sauvegarde tout ce qui a été dit ou pensé par les habitants. Ah oui, c’est pour dans six semaines. »

Évidemment, tout de suite, l’histoire de carrelage tombe un peu à plat.
Mais, pour finir sur une note optimiste, disons qu’elle n’est pas complètement inutile, spécialement si on la considère pour ce qu’elle peut être : une idée régulatrice, autrement dit quelque chose qu’il faut viser.
L’intérêt éventuel de ce que nous a raconté Maurice, c’est de dire : les enfants, pour éviter les débordements, il faut toujours garder à l’esprit que le projet doit tendre le plus possible vers le carrelage. Ça ne sera jamais aussi « simple », mais il faut viser la simplification, l’explicitation des besoins, et les cadrer pour qu’ils soient réalistes et raisonnables. Personne ne demanderait à un carreleur de poser trois niveaux de carrelage, et en or massif, et puis aussi de refaire les peintures au passage (pour le même prix, il va de soi). Ben voilà. Pour nous, ça doit être pareil.

Moralité : la prochaine fois que vous entendez parler de carrelage, soyez attentifs à ce qu’on essaie de vous refourguer comme théorie, il y a de fortes chances pour que ça ne soit pas vraiment approprié.

L’un des grands principes que cette déjà longue et enrichissante vie m’a permis de dégager est le suivant :

Ne pas prendre les gens pour des imbéciles, mais ne jamais oublier qu’ils le sont.

Les gens, ça vaut pour moi aussi, bien sûr ; ça ne veut pas juste dire les-autres-alors-que-moi-je-suis-génial . La base phizolophique de ce précepte est donc toute empreinte de misanthropie (à mes heures perdues, je suis assez misanthrope) ou, pour être plus sympa – et après tout, pourquoi ne serais-je pas plus sympa avec moi-même, se veut un appel à l’humilité. Il aurait pu s’énoncer « si tu trouves que les autres sont cons, dis-toi bien que tu es au moins aussi con qu’eux », mais ça claquait moins, il faut le dire.

Dans la vie de tous les jours (ouvrés), où mes attributions professionnelles m’amènent à côtoyer toutes sortes d’individus qu’on regroupe sous le vocable aussi générique que flou de « client », ce principe a une moultitude d’intérêts et d’applications pratiques.
Il aidera ainsi à éviter de formuler des questions comme si on s’adressait à un demeuré.
Par exemple, ne pas dire « Mais vous êtes sûrs que quand on clique sur Sauvegarder, ça sauvegarde ? » (= vous le prenez pour un abruti, MAL), mais préférer « Que se passe-t-il quand on valide le formulaire ? » (= vous parlez à son intelligence, BIEN). Si le client a effectivement tendance à vouloir inconsciemment réinventer les principes de l’ergonomie, quand ça n’est pas de la mécanique générale, à chaque étape d’un projet, on a aussi une fâcheuse propension à vouloir faire systématiquement le contraire de ce dont il a besoin (ou, au mieux, quelque chose dont il n’a pas vraiment besoin).

En bref, ce principe relève d’une méthodologie simple mais de bon aloi, que la sagesse populaire sait partiellement déjà formuler à sa façon (la paille dans l’œil du voisin et la poutre dans le chien, ou un truc approchant). Quand je vous dis que je suis sage, hein.