Skip links

The glossary (the jargon) of tech and developers

La tech est de ce genre de métier qui va de paire avec un vocabulaire qui lui est propre. Très influencé par l’anglais US, là d’où démarrent beaucoup de choses dans le numérique, le langage des développeurs frise parfois avec un jargonnage bon teint qui éloigne les non initiés d’une saine compréhension. D’où l’idée de rédiger ce glossaire “des 1ers de survie pour converser avec des développeurs” qui sera amené à être régulièrement actualisé.

Le Lead dev : c’est le big boss des équipes Tech, le développeur référent sur un projet public par exemple.

Front-end et Back-end : c’est sûrement les expressions les plus courantes quand on travaille avec des dev. Pour mieux comprendre ces termes, prenons l’exemple d’un site internet. Le front-end désigne toute la partie visible du site internet, l’interface sur laquelle on peut interagir : les curseurs, les polices, les titres, les boutons, les visuels, les animations, les logos, les menus, les rubriques, etc. Le Back-end quant à lui, désigne toute la face cachée derrière le site, aussi invisible qu’essentielle. C’est tout ce qu’il se passe derrière un simple “clic”, la partie que l’utilisateur ne voit pas, mais qui lui permet de réaliser des actions et d’accéder à du contenu. Attention toutefois à la comparaison des développeurs Front et Back ! Les deux métiers ne sont pas les mêmes, mais restent complémentaires.

Le développeur “full-stack”, c’est celui qui sait tout faire : aussi bien du front que du back end !

Back-office : terme qui désigne la partie administrative d’un site web.

Branche, Main, Repo et Commit : Une branche représente une ligne de développement indépendante. Sur la branche principale, souvent appelée “main”, se trouve le code qui sera mis en prod. Lorsqu’on souhaite créer une nouvelle fonctionnalité, on crée une branche. C’est en quelque sorte comme créer une “copie” de la ligne principale pour développer et tester de nouvelles fonctionnalités sans impacter le projet de base. Les branches sont stockées dans un dossier appelé “repo” (de l’anglais repository). Chaque branche comporte des éléments qui sont différents des autres branches. Le commit quant à lui, désigne tout simplement la création d’une nouvelle version de code à partir d’une branche. Tout ceci se trouve sur un “Git”.

Git : c’est la technologie de versioning la plus connue. Cet outil permet de créer une version de code sur un serveur local.

**Git push et git pull** : lorsqu’on Git Push, on envoie son code aux autres dev. Quand on Git pull, on récupère ou télécharge les codes des autres. Pourquoi ? Cela permet de synchroniser son travail local sur un serveur distant, le plus souvent le GitHub.

Github :  c’est l’outil collaboratif par excellence. Il permet de stocker un code source en serveur remote c’est -à -dire dans un serveur distant. Il centralise et stocke ainsi l’historique de toutes les modifications apportées à un projet codé. Ça ressemble à un fichier drive collaboratif.

Pusher/push : désigne simplement quand on effectue une mise à jour, qu’on ajoute une fonctionnalité à un site par exemple (mais ça sonne plus stylé en anglais ).

Merger ou faire un merge (oui oui ça se dit) : c’est lorsqu’on fusionne deux branches.

On a recetté” : il s’agit de “dérouler le cahier de recette” qui correspond à la liste exhaustive des tests à réaliser pour valider le bon fonctionnement d’une nouvelle fonctionnalité. Il s’agit d’une étape essentielle avant de “pousser en prod”.

Pré-production ou préprod pour les intimes : c’est l’étape avant de produire le rendu final. Un environnement de test qui permet de vérifier que tout fonctionne bien avant de “mettre en prod” (ou “déployer en production”).

Pousser en prod : “Je pousse en prod là !” : Termes fréquemment utilisés par les développeurs. C’est l’une des dernières étapes d’un projet : le produit final est disponible publiquement. Par exemple la publication d’une application sur l’AppStore ou Google Play Store.

Refonte : procéder à une modification graphique partielle ou totale d’un site internet ou d’une application.

Travailler en “remote” : c’est travailler à distance. C’est dire qu’on est en télétravail mais dans le langage dev.

Fast track (en français “voie rapide ; accéléré ; raccourci”) : désigne le moment où les dev accélère la cadence pour la réalisation de projet. Pour résumer, on se réunit tous dans une même pièce pour se consacrer à la mise en prod d’un projet.

Hackathon : C’est THE événement qui rassemble des développeurs sur plusieurs jours. Attention ici on ne court pas comme dans un marathon, mais on code ! Au programme : de la programmation, des projets à foison, du partage de compétences, des équipes de travail et le tout dans la bonne humeur.

Framework : littéralement il s’agit d’un cadre… Autrement dit la structure qui caractérise le logiciel. Parce que c’est beau un cadre quand c’est bien posé !

Pentest ou “penetration test” ou encore “test d’intrusion”: Il s’agit d’éprouver la sécurité d’un système par des tests visant à “pénétrer” le système.

FMDS et disponibilité : FMDS est le sigle de fiabilité, maintenabilité, disponibilité et sécurité. La disponibilité c’est le temps durant lequel un système est opérationnel et en état de marche.

Ops / DevOps / DevSecOps : le DevOps représente une démarche dans le développement logiciel qui tend à ne pas dissocier les activités de dev (développement) de celle de l’ops (l’opération, la mise en production et l’administration de l’application développée). A cette fin on essaye de réconcilier, raccourcir, rendre plus agiles et itératives les activités de développement et de mise en production. Ceci touche non seulement les équipes et les compétences qu’elles doivent développer mais aussi le cycle de vie -du design à la mise en production- qui se veut plus rapide, reposant sur des processus plus automatisés, et moins compliqué. Encore une fois ceci repose sur un effort très important d’automatisation des processus. Le Sec entre Dev et Ops consiste à prendre en compte nativement, et notamment dans les phases de test préalables à la mise en production, les questions de sécurité. Ceci concerne essentiellement les applications “exposées” sur internet.

Intégration continue (CI) : facilitateur de la démarche DevOps ! Pour résumer, c’est la matérialisation du travail des DevSecOps : tous les processus de déploiements et de test sont automatisés un maximum et on peut alors “facilement” pousser les nouveaux développements, ce de manière sécurisée et sans perdre de temps.

Run : dans le modèle think-build-run un peu daté mais encore valide pour nombre de développements. Le “run” désigne la phase où l’application / le logiciel / le produit est mis en route (en production opérationnelle) avec une vocation fonctionnelle. C’est en général là que les ennuis commencent.

Non reg (pour “non régression” ou encore “tests de non régression”) : il s’agit de tests ayant pour but de détecter les régressions introduites dans un logiciel après un changement effectué dans celui-ci. On parle de régression lorsqu’une opération effectuée par le logiciel se met à ne plus fonctionner après une modification.

Time-boxing : stratégie de gestion du temps consistant à n’accorder qu’un temps limité à chaque activité. On peut faire un sprint, une réunion ou autre en mode timeboxing.

Best effort : forme d’obligation de moyen. Il s’agit de faire “le mieux qu’on puisse faire” avec les ressources dont on dispose. Exemple : “on va développer cette bouze en best effort”

TTM / time-to-market : il s’agit, en bon français, du “temps de mise sur le marché”. Dans cette logique, un développement TTM consiste à produire une solution strictement dans le temps qui est donné pour sa mise en service.

Kick-off : terme souvent utilisé par les équipes Tech mais qui s’applique à tous les types de projet. Le kick-off d’une réunion désigne la réunion qui précède le lancement d’un projet : on fait le point sur le projet, ses origines, ses objectifs et ses modalités avec toutes les parties prenantes.

Bibliothèque ou plutôt “biblio-Tech” : Eh oui les dev s’y rendent aussi ! Mais attention, on ne parle pas de la même bibliothèque ! On parle ici d’une liste de fonctions pré rédigées (des petits bouts de codes quoi) pour travailler plus rapidement sur un projet.

en_USEN