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 ?

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.

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…