Glossaire

Le jargon IT, en clair

Les articles de ce blog emploient des termes propres au monde informatique. Cette page les rassemble et les explique en langage courant : pas besoin d'être du métier pour suivre.

B

Bus factor: Le nombre de personnes qui devraient disparaître d'un coup d'une équipe pour qu'un projet se retrouve en danger, faute de savoir-faire pour le faire tourner. Le nom vient de l'idée macabre d'un collègue renversé par un bus. Un bus factor de un veut dire qu'une seule personne détient une connaissance que personne d'autre ne possède : un point de fragilité majeur.

E

Error Budget: La dose de pannes qu'un service a le droit de connaître sur une période donnée, fixée à l'avance. Tant que ce « budget » n'est pas épuisé, l'équipe peut continuer à livrer des nouveautés ; une fois dépassé, elle arrête tout pour remettre le service d'aplomb. C'est un curseur entre aller vite et rester stable.

G

Give back the pager: Littéralement « rendre le bipeur ». Quand une équipe spécialisée dans la fiabilité s'occupe d'un service mais que celui-ci reste trop instable, elle peut renvoyer à l'équipe qui l'a conçu la charge d'être d'astreinte, c'est-à-dire joignable jour et nuit pour réparer les pannes. Ce n'est pas une sanction : c'est une façon de rappeler que ce soutien se mérite.

H

Happy path: Le scénario idéal d'un logiciel, celui où tout se déroule comme prévu : l'utilisateur fait ce qui est attendu, sans erreur ni cas imprévu. S'en tenir au happy path, c'est ne gérer que ce cas nominal et laisser de côté les situations exceptionnelles, qui sont pourtant souvent celles qui causent les pannes.

I

ITIL: Ensemble de bonnes pratiques, largement adopté, pour organiser le travail quotidien d'un service informatique : répondre aux demandes des utilisateurs, gérer les pannes, encadrer les changements. L'idée est de donner à tout le monde une méthode et un vocabulaire communs, plutôt que d'improviser chacun dans son coin.

P

Pair-coding: Façon de programmer à deux sur un même travail : un développeur écrit le code pendant que l'autre suit, commente et oriente en temps réel, les rôles s'échangeant régulièrement. Plus lent en apparence, mais la connaissance se partage au fil de l'eau et les erreurs se repèrent aussitôt. On parle aussi de « programmation en binôme ».
Product Owner: Dans une équipe qui développe un produit, la personne chargée de décider quoi construire et dans quel ordre, au nom des clients et de l'entreprise. Elle traduit les besoins en une liste de priorités pour les développeurs et tranche sur ce qui passe avant le reste. Elle décide du « quoi », pas du « comment » : elle connaît le produit tel qu'il doit servir, pas forcément les rouages techniques qui le font marcher.

R

Refactorer: Remettre de l'ordre dans un code existant pour le rendre plus clair et plus facile à modifier, sans rien changer à ce qu'il fait. Ce n'est ni corriger un bug ni ajouter une fonctionnalité : c'est de l'entretien, comme on rénove un bâtiment pour qu'il ne se dégrade pas. À force de ne pas le faire et d'empiler les rustines, le code devient de plus en plus coûteux et risqué à faire évoluer.
RUN: Tout ce qui consiste à faire tourner les systèmes informatiques au jour le jour : surveiller, dépanner, maintenir, assister les utilisateurs. On l'oppose au « BUILD », qui regroupe les projets qui construisent ou transforment ces systèmes. Faire vivre l'existant d'un côté, bâtir le neuf de l'autre. Quand le RUN dévore tout le budget et toute l'énergie, il ne reste plus rien pour innover.

S

SLA (Service Level Agreement): Engagement chiffré sur la qualité d'un service, inscrit dans un contrat : par exemple un service disponible 99,9 % du temps, ou une panne prise en charge en moins d'une heure. Le SLA transforme une promesse vague en obligation vérifiable, souvent assortie de pénalités si elle n'est pas tenue. « Exploser le SLA », c'est dépasser ces limites, donc être en faute vis-à-vis de l'engagement pris.
SRE (Site Reliability Engineering): Façon de travailler, née chez Google, pour qu'un service en ligne reste fiable, autrement dit qu'il fonctionne sans tomber en panne. Plutôt que de compter sur les efforts héroïques de quelques personnes, on fixe des objectifs de fiabilité chiffrés et on s'en sert pour décider quoi faire en priorité.