Glossaire technique à l’usage des non-informaticiens du secteur IT

Le secteur des technologies informatiques est indéniablement tendu, en France et dans le monde. Beaucoup de jeunes choisissent de grossir les rangs des développeurs et informaticiens en tous genres. Mais pour chaque profil technique sur le marché de l’emploi :

• des recruteurs vont chercher à le faire intégrer leur entreprise,
• des commerciaux de sociétés de services vont tenter de le placer chez leurs clients,
• des managers vont orienter sa carrière, etc.

Toutes ces personnes doivent communiquer avec les profils techniques, comprendre ce qu’ils ont fait durant leur parcours mais également ce qu’ils souhaitent faire aujourd’hui, demain, dans dix ans. Et ce n’est pas toujours facile ! Le jargon informatique aurait souvent besoin d’une traduction simultanée…

J’ai toujours beaucoup aimé cette image, certes un peu caricaturale, mais qui traduit très bien la fracture qui peut exister entre les développeurs et ceux qui ne parlent pas leur langage. On pourrait ici remplacer « users » par beaucoup d’autres intitulés… Toutes mes excuses à l’auteur de ce dessin pour ne pas le citer. Elle a tellement circulé sur le net que j’aurais bien du mal à en retrouver la source.

L’idée de ce glossaire est née de ce constat d’incompréhension. Il a vocation à vulgariser, parfois à l’excès, certains termes techniques obscurs, dont les non-informaticiens (et parfois même les informaticiens eux-même) peinent à cerner les notions qu’ils véhiculent. On s’attachera également à démystifier certains termes employés plus pour leur connotation que pour leur sens.

L’objectif est qu’en quelques lignes n’importe qui soit capable d’avoir un aperçu de ce qui se cache derrière un mot, de façon à pouvoir interagir normalement avec une personne qui l’utilise.

Dans l’ordre d’apparition (faute d’avoir un vrai sommaire) :

• agile
• architecte / architecture
• back, back-end, front, front-end, fullstack, etc.
• big data
• blockchain
• client / serveur
• cryptage, décryptage, chiffrement, déchiffrement, etc.
• dette technique
• devops
• digital
• distribué (dans « base de données distribuée »)
• ETL
• framework
• java / javascript
• langage (de programmation)
• librairie
• mobile first
• n-tiers (dans « architecture n-tiers »)
• responsive design
• scrum
• UX

Ce n’est pas exhaustif. J’ai publié l’article car j’estimais qu’il était assez fourni pour une première édition. Mais n’hésitez pas à me transmettre les termes courants et mal compris que vous pouvez rencontrer au quotidien ! Et même si vous avez finalement compris ce qui se cachait derrière un mot, pourquoi ne pas en faire bénéficier d’autres ? De même, si vous connaissez des ressources (articles, sites, livres) bien conçues qui permettraient à des néophytes de pousser plus loin leur compréhension de certains sujets, faites m’en part et je pourrai les rajouter aux paragraphes « En savoir plus… ».

Glossaire

Première édition.

agile

On parle beaucoup des méthodes agiles ces derniers temps ! Tout cela découle de grands principes de développement logiciel décrits dans un manifeste par des experts du domaine. Ils ont été repris et traduits par notre ami Wikipédia. Ce manifeste décrit 4 valeurs et 12 principes à appliquer pour « mieux » développer des applications informatiques. Les méthodes agiles sont, par extension, les méthodes de travail qui respectent ces valeurs et principes. À ma connaissance, il n’existe pas de norme, de label ou de certification : toute méthode « maison », développée en interne, qui respecte ces principes peut être considérée comme agile.

Les valeurs et principes étant décrits de façon très ouverte, ils sont sujet à interprétation. Et on entend souvent le terme « agile » ou « agilité » employé à tort et à travers, parce que c’est la mode, ça fait classe. Les éditeurs de logiciels destinés aux entreprises et aux développeurs surfent également sur cette « vague agile ». Donc attention aux raccourcis !

architecte / architecture

Ce terme évoque instantanément le BTP. Sans contexte, un « architecte » c’est quelqu’un qui dessine des maisons. C’est la personne qui s’assure qu’elles tiennent debout, de la conception jusqu’à la fin du chantier, qui imagine le découpage de l’espace et l’agencement des pièces, les matériaux à utiliser, etc. Elle conçoit le résultat final avant qu’on donne le premier coup de pelleteuse.

Dans l’informatique, c’est exactement la même chose, mais avec des systèmes informatiques ! L’architecte logiciel est la personne qui va réfléchir à la structure d’un système, dès sa conception. Il va prendre connaissance du besoin métier et en déduire les contraintes techniques associées, commencer à imaginer le squelette et le découpage du système, avant même que la première ligne de code ne soit écrite. Quel(s) framework(s) utiliser ? Comment découper le code pour le rendre efficace et maintenable ? Et la sécurité dans tout ça ? Etc. Je ne fais pas de liste trop longue : ça ne serait intéressant ni à lire ni à écrire.

Une fois les travaux commencés, quand les développeurs ont attaqué la réalisation, l’architecte reste présent pour s’assurer que tout se déroule comme prévu et, en cas de besoin, parer proprement et solidement à l’imprévu. Mais une fois la conception réalisée et les plans remis au maître œuvre, la part la plus importante de son travail est terminée.

back, back-end, front, front-end, fullstack

Ces termes peuvent qualifier une partie d’un logiciel ou un profil de développeur. Il existe de nombreux articles sur le net qui tentent de les expliquer.

Pour faire ultra-simple :

• front (ou front-end, c’est pareil) désigne la partie d’une application qui est visible par l’utilisateur et dont il va se servir. Le plus souvent : ce qui s’affiche à l’écran. Un développeur front est un développeur qui maîtrise les technologies informatiques nécessaires à la réalisation de cette partie de l’application.
• back (ou back-end, c’est pareil) désigne la partie d’une application non visible à l’utilisateur. Toute la « machinerie » qui permet à la partie front de fonctionner : les logiciels côté serveur, les bases de données, etc. Un développeur back est un développeur qui maîtrise, souvent en partie car c’est un vaste domaine, les technologies informatiques nécessaires à la réalisation de cette partie de l’application.
• Le développeur fullstack (sans aborder le débat relatif à son existence) est polyvalent : il peut intervenir sur les technologies côté front ou côté back. Il est par conséquent moins spécialisé dans un domaine, moins « expert » dans une technologie en particulier.

Le travail « côté front » n’est ni plus simple ni plus complexe que le travail « côté back ». Les concepts et langages impliqués sont juste différents, avec des objectifs et contraintes différentes.

Et un développeur fullstack n’est pas plus compétent que les autres. Devant la multiplication des technologies et outils informatiques, les développeurs doivent se spécialiser s’ils veulent espérer rester « à la page » dans leur domaine. Certains font donc ce choix de spécialisation front/back, d’après une préférence personnelle ou simplement suite à une expérience réussie. D’autres préfèrent rester polyvalents, tout en acceptant d’avoir souvent un train de retard dans certains domaines…

En savoir plus… Si vous voulez creuser les subtilités de ces notions, ou avoir un aperçu des technologies impliquées de chaque côté, je vous encourage à taper « front back fullstack » sur Google : la lecture des 3 premiers articles devrait suffire.

blockchain

Les médias se régalent de ce terme en ce moment, les entreprises aussi. Il fait moderne et innovant. L’entreprise qui propose un produit dont le nom contient « blockchain » est forcément à la pointe de la technologie, non ? Non. Il y a un effet « woaw » autour de ce terme, qui n’est pas forcément justifié lorsqu’on le comprend.

Pour résumer, une « blockchain » est une chaîne de blocs (jusque-là, vous l’aurez peut-être déviné tout seul), une chaîne de données ordonnées et reliées les unes aux autres. Dans le domaine financier, où la notion est très employée, les données peuvent être des transactions financières, l’une ayant eu lieu avant l’autre. On sait donc identifier le « bloc » de données précédent et le « bloc » suivant. Jusque-là rien de très mystérieux.

L’innovation (et pas la « révolution », car il n’y a finalement rien de très révolutionnaire là-dedans) réside dans le mécanisme utilisé pour rendre cette chaîne inaltérable. Chaque bloc contient non seulement ses propres données, mais également une image du bloc précédent. Ainsi, si quelqu’un altère les données d’un bloc, l’image contenue dans le bloc suivant ne correspond plus. On dit que la chaîne n’est plus « validée ». Si la vérification de la validité de la chaîne est effectuée suffisamment souvent, on se protège ainsi de toute modification des blocs existants : une personne qui voudrait modifier un bloc sans que cela ne se voit devrait également modifier tous les blocs suivants jusqu’à la fin de la chaîne.

« C’est tout ? » Oui. Le concept de « blockchain » se résume à ça. Je ne dis pas que c’est sans intérêt, bien au contraire : c’est très bien pensé ! Et ça sera probablement utile dans beaucoup de domaines. D’autant plus que c’est finalement un concept assez simple. Mais ce n’est ni magique, ni applicable à tous les types de données. Cela n’a pas forcément d’intérêt dans tous les cas d’utilisation.

« Du coup, pourquoi on en fait tout un foin ? » Quand on parle « blockchain », on parle aussi souvent de Bitcoin et de crypto-monnaies, car c’est dans ce domaine que le concept a vu le jour. Bitcoin se base sur une blockchain distribuée, c’est-à-dire qu’elle n’est pas stockée à un endroit précis mais partout à la fois, avec des mises à jour de toutes ces copies en quasi-temps réel et un mécanisme de validation de la chaîne très poussé. C’est là que réside la véritable révolution du Bitcoin ! La blockchain n’est ici qu’un outil parmi d’autres.

La plupart des articles non spécialisés qui emploient le mot « blockchain » le font sans savoir ce que ça signifie. Ne tombez pas dans ce travers ! 🙂

En savoir plus… J’ai publié le lien vers un article en deux parties qui explique très bien et plus en détail ces concepts. Je l’ai d’ailleurs moi-même utilisé pour les comprendre. Voici la première partie : Everything You Wanted To Know About Blockchains (en anglais par contre).

big data

J’ai trouvé la définition de l’article Wikipédia français très bien, donc je ne vais pas me fatiguer à en faire une moi-même : « Le big data désigne des ensembles de données devenus si volumineux qu’ils dépassent l’intuition et les capacités humaines d’analyse et même celles des outils informatiques classiques de gestion de base de données ou de l’information« . Partant de là, je vais élaborer un peu.

C’est donc une branche de l’informatique qui touche aux très gros volumes de données. On parle ici de bases de données qui représentent plusieurs téraoctets (To) d’espace de stockage. Quand le volume des données prend ce genre de proportion, il faut adapter quelques petites choses :

• La façon de les stocker, pour pouvoir y accéder facilement. Imaginez que vous avez des milliards de livres dans votre bibliothèque (parce que vous avez hérité d’un très très grand château où les ranger), et qu’un ami vous demande de lui en prêter un en particulier. Vous avez intérêt à avoir un sacré système de classement pour le retrouver en moins de 10 ans ! Pour les données, c’est la même chose. Si vous voulez un accès quasi-instantané à une ligne de données dans une base de 3To, il faut concevoir les systèmes appropriés pour rendre cela physiquement possible.
• La façon de les utiliser. Retournons dans votre grande bibliothèque dans votre grand château. Vous avez réussi à trouver le livre à prêter à votre ami (bravo !). Il le lit et l’apprécie. À tel point qu’il vous demande si vous n’auriez pas un autre livre du même style à lui prêter. Déjà, que veut-il dire par « du même style » ? Du même auteur ? De la même série ? Avec un style d’écriture similaire ? Dont l’histoire se déroule à la même époque ? Si vous aviez 10 livres en stock, le choix serait peut-être vite fait. Mais dans votre bibliothèque de milliards de livres, ça devient plus compliqué…

En rapprochant cela du domaine big data, on peut imaginer un algorithme qui fait tous les rapprochements possibles entre tous vos livres pour dénicher la perle, LE livre qui plaira à coup sûr à votre ami !

C’est une grosse part du travail des data scientists : analyser les données pour en tirer de la valeur. En regroupant en très grand nombre et en analysant des données qui, seules, n’ont pas une très grande valeur, on peut réussir à faire apparaître des schémas, des tendances, des informations dont la valeur est supérieure à la somme de celle de toutes les données séparées.

Tout cela devient possible aujourd’hui parce que les technologies le permettent :

• On parvient à stocker plus sur des supports plus petits.
• La puissance de calcul des ordinateurs ne fait qu’augmenter.
• Avec tous les appareils connectés et le nombre croissant de personnes qui les utilisent, de plus en plus de données sont disponibles à qui veut bien prendre la peine de les stocker et de s’en servir (oui, la plus grande source de données, c’est vous et moi !).

On commence à peine à découvrir le potentiel de ce domaine informatique, qui s’applique à quasiment tous les secteurs d’activité : agriculture, santé, publicité, environnement, recherche scientifique, etc.

client / serveur

Comme l’explique notre ami Wikipédia, cette notion désigne « un mode de communication à travers un réseau entre plusieurs programmes« . Le client envoie une requête vers le serveur. Celui-ci réalise des opérations et renvoie finalement une réponse.

L’image la plus classique est celle de la consultation d’une page web. Simplifiée à l’extrême, voilà ce que ça donne :

• Vous tapez une adresse web (URL) dans la barre d’adresse de votre navigateur web.
• Votre navigateur, ici le client, envoie la requête que réprésente cette adresse sur le réseau Internet.
• Par un mécanisme que je n’expliquerai pas ici, cette requête atteint un gros ordinateur, quelque part dans un hangar à l’autre bout du monde, qui est censé vous fournir la page web demandée. C’est le serveur.
• Ce serveur construit donc le contenu de la page web, en fonction de ce que vous avez demandé, et la renvoie à votre navigateur via le réseau Internet. Le contenu de cette page web est la réponse du serveur.
• Enfin, votre navigateur vous affiche la page web à l’écran, à partir de ce qu’il a reçu de la part du serveur.

cryptage, décryptage, chiffrement, déchiffrement, etc.

Vous ne rencontrez peut-être pas ces termes fréquemment au quotidien. Mais je me dois de les expliquer rapidement car je les entends très souvent mal utilisés. Encore une fois, je vais essayer de l’expliquer aussi simplement que possible, quitte à prendre quelques raccourcis.

Sachez qu’il existe des désaccords sur certains de ces termes : leur définition et leur usage ne fait pas l’unanimité. Pour ma part, je me range du côté de ce site très bien fait, qui se base lui-même sur le RGS de l’ANSSI.

Commençons par crypter / cryptage : ce sont des pseudo-synonymes pour chiffrer / chiffrement, qui sont ambigus. On peut les confondre avec hacher / hachage. Le plus simple est d’éviter de les utiliser. Il est préférable de privilégier les termes que tout le monde comprend de la même façon !

Chiffrer une information, c’est la rendre incompréhensible à toute personne qui ne dispose pas de la clé pour la déchiffrer. Le processus s’appelle le chiffrement (et pas le chiffrage !!) et est réversible : on peut retrouver l’information d’origine à partir de sa version chiffrée, du moment qu’on dispose de la clé.

Décrypter une information chiffrée signifie réussir à lire cette information sans posséder la clé de déchiffrement. D’une certaine façon, c’est « casser » le chiffrement pour parvenir à lire une information à laquelle on n’est pas censé avoir accès.

En cryptographie, on peut également rencontrer les termes hacher / hachage (dont je ne suis pas sûr de l’existence réelle dans la langue française). Le hachage est un procédé qui, à partir d’une information, produit une empreinte, une image de cette information, la plupart du temps incompréhensible. Mais ce processus est à sens unique : on ne peut pas retrouver, par calcul, l’information initiale à partir de l’image !

dette technique

C’est un vaste sujet, parfois source de conflit sur les projets. Et pas forcément simple à expliquer en quelques lignes. Pour résumer, on peut voir la dette technique comme le décalage entre l’état technique d’un logiciel à un moment donné (la façon dont son code est écrit, les langages et outils utilisés, etc.) et ce qui se fait de mieux, dans le domaine, à ce même moment. On accumule ce décalage tout au long de la vie d’un projet : la dette techique est inévitable, du fait du progrès technologique et de l’imperfection humaine (personne ne code parfaitement bien en permanence). Le tout est de savoir comment la gérer, la réduire de façon régulière pour qu’elle n’impacte pas trop la productivité de votre équipe.

En savoir plus… J’ai écrit un article sur le sujet, qui mentionne lui-même d’autres lectures conseillées : Comprendre ce qu’est la « dette technique ».

devops

Encore un terme très à la mode dans les conférences et articles IT ! Il qualifie une méthode, une volonté, une démarche que je vais essayer d’expliquer ci-dessous.

Aux débuts de l’informatique, il y avait les informaticiens (*musique de l’Odyssée de l’espace de Kubrik*). Une seule équipe pouvait se charger de tout le développement d’un logiciel : sa conception, son développement, son déploiement, sa maintenance et l’entretien de la machine à café. Mais les applications ont grossi, les réseaux internes aussi, Internet est apparu, etc. Tout cela a fortement augmenté la charge de travail liée au développement d’un produit informatique, et il a fallu découper ce travail entre plusieurs équipes. Deux profils-types sont alors apparus : dev et ops.

Dev, pour « development » en anglais, qualifie les équipes (ou les membres des équipes) qui créent et font évoluer l’application en elle-même. Ops, pour « operations » en anglais, qualifie les équipes qui mettent en place et maintiennent tout ce qui permet à l’application de fonctionner : le réseau, les serveurs, les bases de données, etc. Ce sont des métiers très différents, car les technologies utilisées sont différentes, la logique est différente, les méthodes de travail aussi.

Une différence, en particulier, a causé du tort à l’efficacité de l’ensemble de la chaîne de production : les objectifs de chacun. Les ops ont pour mission de garantir le fonctionnement et la stabilité de l’application. Les dev ont pour mission de faire évoluer l’application, donc d’y apporter des changements. Et le changement ce n’est pas bon pour la stabilité… De cette incompatibilité d’objectifs est née une sorte de rivalité entre ces deux profils / équipes. C’est souvent un peu la guerre entre dev et ops : les premiers reprochant aux seconds d’être immobilistes, les seconds reprochant aux premiers d’être des cowboys.

La démarche devops a pour objectif de redonner un même objectif à ses deux équipes et de les refaire travailler ensemble, en s’inspirant des méthodologies agiles : l’objectif final, pour tout le monde, est que le client soit satisfait du produit. Chaque profil apporte ainsi ses compétences et bonnes pratiques à l’autre et intervient à toutes les étapes de la création d’un produit, pour fluidifier la chaîne de production. Il n’y aurait alors, à nouveau, plus qu’une seule équipe mais qui contiendrait les deux types de profils.

Attention, devops n’est pas un type de poste ! « Je suis devops » ne veut absolument rien dire… « Je cherche un devops en CDI » non plus.

digital

Dans la langue française, digital signifie « qui appartient aux doigts, se rapporte aux doigts », comme dans « empreintes digitales » par exemple. À ne pas confondre avec numérique, « qui a rapport aux nombres ». « Numérique » peut également être utilisé comme alternative à « analogique » : un appareil numérique représente une grandeur physique sous forme de nombre alors qu’un appareil analogique la représente sous forme d’une autre grandeur physique. Ce qui explique qu’on retrouve beaucoup l’adjectif « numérique » dans l’informatique, où tout est représenté et enregistré avec des nombres…

Malheureusement, en anglais, la traduction de « numérique » est… « digital » par extension de « digit », qui signifie « chiffre ». Et employer un mot anglais comme si c’était du français, c’est bien vu dans les sphères médiatiques. Ça fait le « buzz ».

Mais c’est aussi vu comme du « marketing bullshit » par certaines personnes (dont moi, au cas où ce n’était pas encore clair ^^), notamment parmi les profils techniques, qui aiment le concret. À force d’être employés à tout bout de champ pour leur connotation, faute d’avoir un sens dans le contexte dans lequel ils sont utilisés, ces mots deviennent creux, des coquilles vides qui parsèment des articles ou des présentations. Et cette image se répercute alors sur les personnes qui les utilisent…

Bref, quand vous parlez d’un « projet digital » à quelqu’un, vous lui parlez d’un projet de doigts… La « transformation digitale d’une entreprise », c’est la transformation de ses doigts. Ou des doigts de ses salariés, faute de trouver ceux de l’entreprise. Je pourrais donner d’autres exemples rigolos, mais je pense que vous avez compris le principe.

Si vous vous sentez concerné par ce paragraphe, il n’est jamais trop tard pour changer ! Arrêtez le bullshit et remettez du sens dans ce que vous dites ou écrivez en français.

distribué

En ce moment, avec la fureur des crypto-monnaies, on entend souvent parler de bases de données distribuées. C’est donc principalement dans ce contexte que je vais expliquer le terme.

Une base de données, c’est un serveur, quelque part dans un hangar climatisé, où sont enregistrées des données de toute sorte. Même s’il existe des sauvegardes, les données restent centralisées à un endroit. Une entreprise en est garante et les fournit à tous les composants qui peuvent en avoir besoin.

Imaginez une attaque informatique de grande ampleur ciblant cette entreprise ou une catastrophe naturelle impactant le site de stockage. Les données qui y sont enregistrées peuvent être temporairement inaccessibles, perdues, corrompues, etc. Plus simplement, imaginez qu’un employé débranche le mauvais câble : le serveur qui héberge votre base de données n’est plus alimenté. Plus de données, plus de service !

Le principe d’une base de données distribuée est de s’affranchir autant que possible de ce risque. Sans rentrer dans le détail, on va dupliquer ces données à plusieurs endroits, en les isolant autant que possible : serveurs physiquement séparés, voire situés dans des pays différents, sur des réseaux différents, etc. Tout cela de façon à ce qu’un incident qui impacterait une des copies n’impacte pas les autres. On peut ainsi garantir un service constant : si une des « instances » de la base de données est coupée, les autres sont là pour assurer le service.

On comprend bien que si on stoque 50% des données sur une base et les 50% restants sur une autre, et que le hangar de la première brûle, on perd 50% des données… Il faut donc que chaque instance soit auto-suffisante. Des mécanismes existent pour synchroniser, en temps réel ou non, ces différentes bases. Mais je ne rentre pas dans le détail de ces mécanismes, d’une part parce que ce n’est pas ma spécialité, mais aussi parce que si vous avez compris le principe, c’est déjà pas mal !

ETL

ETL est l’acronyme de « Extract Transform Load » et désigne des outils de transfert de données entre plusieurs systèmes informatiques. Ces outils sont conçus pour extraire les données d’un système (Extract), leur appliquer des traitements (Transform) et les charger dans un second système (Load). De ce fait, ils sont spécialisés dans la compatibilité, car ils doivent se connecter à des systèmes très différents, et la manipulation de données.

framework

Pour bien comprendre la notion de framework, il faut d’abord comprendre la notion de langage (décrite plus bas). Je vous encorage donc à aller voir ce terme si vous n’en maîtrisez pas trop le sens.

Pour faire simple, un framework est une boîte à outils. C’est un ensemble d’éléments (composants logiciels, principes de fonctionnement, squelette d’application générique, etc.) qui permet de construire un logiciel, une application, un site web. Si on fait l’analogie avec une vraie boîte à outils : le marteau, la scie, la perceuse sont des petites constructions mécaniques, plus ou moins complexes, qui vous permettent de fabriquer d’autres choses. C’est exactement pareil pour le framework !

La plupart des frameworks se basent sur un langage de programmation spécifique pour construire les briques logicielles de base. Certains sont spécialisés pour des types de constructions différents : on n’utilise pas le même genre de framework pour construire un site web ou un logiciel embarqué dans un sous-marin. De même, pour construire un bateau en bois, vous utiliserez plutôt la scie, le marteau, les clous, la ponceuse. Alors que pour construire un portail en fer forgé, ces outils ne seront pas du tout adaptés !

Comme pour les langages, les frameworks sont extrêmement nombreux. Il est d’ailleurs souvent difficile pour des néophytes de faire la distinction entre les deux. Si vous cherchez un développeur qui a déjà fait du Javascript (langage), il faut pouvoir identifier qu’un CV qui mentionne « jQuery », « AngularJS » ou « React » correspond au besoin : ce sont 3 frameworks (parmi beaucoup d’autres) qui utilisent le langage Javascript. On voit d’ailleurs souvent des articles qui mettent tous ces termes au même niveau et les comparent les uns aux autres, renforçant l’amalgame par la même occasion…

Malheureusement, pour réussir à distinguer frameworks et langages et associer les uns aux autres, je n’ai pas de recette magique. C’est une habitude à prendre. J’ai cherché un graphique qui reprendrait les principaux frameworks en vogue en les associant au langage utilisé : je n’ai pas trouvé grand chose. La difficulté étant que la liste de ces frameworks les plus populaires change en permanence avec l’arrivée de nouveaux. Un bon exercice peut être de lister quelques langages que vous rencontrez souvent et de choisir une couleur pour chacun. Ensuite, sur un support quelconque (tableau blanc, cahier, slide PPT), pour chaque nom de framework que vous croisez : recherchez quel est le langage utilisé (ou le demander à un dev qui traine à la machine à café) et écrivez-le dans la couleur choisie pour ce langage. Gardez cet aide-mémoire de côté, complétez-le et ça finira par rentrer ! 😉

java / javascript

Oui, ça commence pareil. Non, ça n’a rien à voir ! Le seul point commun de Java et Javascript est que ce sont deux langages de programmation. Et on peut raisonnablement admettre de s’arrêter là pour les points communs…

Java est un language de programmation côté serveur (voir l’explication client / serveur si je vous ai perdu), développé par Sun Microsystems, racheté plus tard par Oracle.

Javascript était à la base un langage côté client, utilisé pour animer les pages web et développé par Netscape. Son utilisation commence à se développer également côté serveur, mais ce n’est pas l’objet du propos.

L’origine de la similitude de ces 2 noms est purement marketing, Javascript ayant été développé lors de la montée en puissance de Java.

À noter qu’un expert Java ne sera pas forcément expert en Javascript, et inversement. Je le répète : aucun lien.

langage (de programmation)

Le terme « langage » reflète très bien ce que c’est : c’est un « outil » qui permet de dialoguer, de se comprendre, de passer des consignes.

Appliqué à l’informatique, un langage de programmation est un langage qui nous permet de dialoguer avec un ordinateur, de façon à lui faire exécuter des actions selon une certaine logique. Ce mélange d’actions et de logique s’appelle un « algorithme ».

À la base, le processeur d’un ordinateur ne comprend que deux choses : 0 et 1. Les « consignes » qui lui sont passées sont donc une suite de 0 et de 1 : on parle de système binaire. Mais, aujourd’hui, il serait inconcevable de construire un logiciel ou un site web en binaire… Ce serait beaucoup trop long et fastidieux. Et les informaticiens ont fait ce constat depuis longtemps ! C’est pourquoi, depuis l’apparition de l’informatique, des langages de plus en plus évolués se sont développés. Dans un premier temps, on a groupé ces 0 et ces 1 par groupes de 8 (les octets), en donnant un sens à chaque combinaison. Puis on a utilisé ces octets pour construire des éléments et des logiques de plus en plus évolués. Chaque nouvelle « couche » de langage permettant de faciliter la construction de la couche précédente. Aujourd’hui, les langages possèdent leurs propres vocabulaire et instructions qui, à force d’interprétation par les différentes couches, sont transformées en instructions binaires pour les processeurs.

Pour résumer, un langage est un ensemble de mots et de règles d’utilisation de ces mots qui permet de formuler des consignes pour un ordinateur. Comme il existe de très nombreuses langues parlées dans le monde, il existe de très nombreux langages de programmation. Chaque langage a ses spécificités, ses points forts, ses inconvénients, etc.

librairie

C’est l’endroit où on va acheter ses livres d’informatique (oui oui, on a des livres aussi !), mais pas uniquement ! On appelle aussi librairie (par anglicisme) une bibliothèque logicielle : un petit composant logiciel autonome, prêt à l’emploi, qu’on utilisera pour un but bien précis.

Par exemple, on utilisera une librairie pour chiffrer une chaîne de caractères (voir la section dédiée de ce glossaire ! Ou « la super technique pour faire des renvois internes »…), mettre en place des paiements en ligne, afficher une carte ou communiquer avec une base de données.

Ne pas confondre avec un framework, qui est une boîte à outils générique permettant de faire tout et n’importe quoi. La librairie a un usage bien précis et peut être utilisée en l’état. C’est un raccourci, mais on peut considérer qu’un framework est un ensemble de librairies liées avec un peu de code pour former une trousse à outils complète.

mobile first

La notion de mobile first (traduction : « le mobile d’abord ») est très liée à celle de responsive design, à tel point que les gens confondent souvent les deux, à tort.

La démarche mobile first consiste à concevoir un site web ou une application en premier lieu pour un usage sur smartphone. Tout est pensé, à la base, pour que les utilisateurs s’en servent depuis leur téléphone. L’aspect adaptatif (voir la définition de responsive design) ne sera ajouté qu’après, rendant ainsi le produit utilisable sur d’autres supports que le smartphone.

Tout site web adaptatif n’est pas forcément mobile first… C’est une technique de conception bien spécifique, qui requiert une grande maîtrise des schémas d’utilisation sur un smartphone : aspect tactile, mouvement des doigts, défilement, etc.

n-tiers

Ce terme désigne un type d’architecture logicielle selon laquelle l’application est découpée en couches, chacune ayant un rôle bien défini. Le plus simple est de prendre l’exemple de l’architecture « 3-tiers », très courante. Comme son nom l’indique, cette architecture comprend 3 couches :

• la couche de présentation, qui se charge de la restitution des informations au client. Pour un site web, par exemple, c’est la couche logicielle qui va construire le HTML qui sera envoyé au navigateur.
• la couche logique, qui réalise tous les traitements logiques. Pour un site marchand : l’utilisateur est-il connecté ? A-t-il rempli son panier ? Si oui, qu’y a-t-il dedans ? Pourrait-t-on lui proposer un autre article en lien avec ce qu’il a déjà ? etc.
• la couche d’accès aux données, qui dialogue avec la base de données. Elle transforme les consignes de la couche logique en instructions compréhensibles par le moteur de la base de données.

L’objectif est de rendre chaque couche plus facile à maintenir et plus réutilisable. L’article Wikipédia anglais sur le sujet est une lecture intéressante et un point de départ pour la découverte d’autres concepts d’architecture.

responsive design

Le design adaptatif, appelé responsive design par la plupart des gens, est une pratique de conception qui vise à rendre la consultation d’un site web confortable et ergonomique quel que soit le support utilisé par l’internaute. Que ce soit avec un PC de bureau, un smartphone, une tablette, l’utilisateur aura une expérience facile et intuitive, adaptée au support.

La gestion du défilement (bien plus simple avec un ordinateur qu’avec un smartphone) et l’aspect tactile du support (qui permet de faire glisser des éléments mais pas de faire un clic droit de souris) sont des exemples de choses auxquelles il faudra apporter une attention particulière lors de la conception d’un site adaptatif.

scrum

Là, on va rester très factuel : Scrum est une méthode agile, parmi d’autres. Je vous renvoie donc à la définition de « agile » si vous ne la connaissez pas ! 🙂

Scrum master est un terme qu’on peut voir associé à un profil. C’est un des rôles définis par la méthode Scrum : c’est la personne qui va guider une équipe dans l’application de cette méthode.

En savoir plus… scrum.org ou Wikipédia !

UX

C’est l’acronyme de User eXperience, la lettre X se prononçant « ex » en anglais. Je ne suis pas un expert dans le domaine, loin de là. Donc je vais essayer de le définir avec mes mots. Je laisse les experts qui liront ces lignes me corriger si je m’égare ou si ma description est incomplète. Mais j’ai cru comprendre que, même parmi les experts, tout le monde ne tombe pas d’accord sur la définition de ce concept assez récent.

UX est une démarche de conception et d’analyse des outils informatiques dans laquelle on essaie réellement de se mettre à la place d’un utilisateur. L’ergonomie rentre bien évidemment en ligne de compte, mais pas seulement. Il y a également une part de psychologie dans l’expérience utilisateur. Quel effet va avoir l’application sur l’utilisateur ? Comment va-t-il réagir, même inconsciemment ?

Voici quelques exemples qui me viennent en tête et qui sont, de mon point de vue, liés au domaine de l’UX :

• la frustration ou l’agacement engendré par une action trop répétitive ou dont l’effet est trop lent,
• l’impression de gain et l’addiction qu’elle génère,
• la façon de concevoir un formulaire de façon à ce qu’un maximum d’utilisateurs le remplissent jusqu’au bout.

Remerciements

• Je remercie Coralie Nohel pour avoir osé me poser ses questions, alors qu’elle ne me connaissait pas du tout. Ce fut un plaisir d’y répondre et l’idée de ce glossaire est née pendant notre discussion sur LinkedIn.