Le jargon des développeurs, traduit en français courant

Vous avez déjà assisté à une réunion avec des ingénieurs ? Ou regardé l’écran d’un ami développeur plus de trente secondes ? Alors vous avez forcément entendu ces mots. Token. Pull request. CI/CD. Repo. Déployer. Tout le monde les emploie comme si on naissait avec.

Personne n’est né avec. Derrière chacun de ces termes se cache une idée étonnamment simple, une fois qu’on enlève le vernis technique. Alors enlevons-le.

Token

Un token, c’est une clé numérique. Quand une application doit prouver son identité, à un serveur ou à une autre application, elle présente un token au lieu d’un identifiant et d’un mot de passe.

Imaginez la carte magnétique d’un hôtel. À la réception, on vérifie votre identité une seule fois, puis on vous remet une carte qui ouvre votre chambre. Vous n’avez pas à vous présenter à chaque passage devant la porte : la carte parle pour vous. Et comme une carte d’hôtel, un token expire, peut être limité à certaines portes, et peut être annulé sur-lechamp s’il est volé, sans que votre identité elle-même soit compromise.

Petite subtilité qui sème la confusion : dans le monde de l’intelligence artificielle, « token » désigne tout autre chose, à savoir un petit morceau de texte (à peu près un mot, parfois moins) que les modèles de langage lisent et produisent. « Ce modèle coûte 3 dollars le million de tokens », c’est une histoire de bouts de texte. « Mon token d’API a fuité », c’est une histoire de clé. Même mot, deux univers. Le contexte fait le tri.

Repository (ou « repo »)

Avant de comprendre les pull requests, il faut passer par ici. Un repository, c’est tout bêtement le dossier où vit le code d’un projet, accompagné de tout son historique : chaque modification jamais faite, par qui, et quand. Des plateformes comme GitHub hébergent ces dossiers en ligne pour que les équipes travaillent sur le même code sans s’envoyer des fichiers zip par mail comme en 2004.

Commit

Un commit est un instantané du code à un moment donné, assorti d’une petite note qui décrit le changement (« correction du bug de connexion », « ajout du mode sombre »). L’historique d’un projet n’est rien d’autre qu’une longue chaîne de commits. Si quelque chose casse, on peut revenir à n’importe quel instantané précédent. Voilà pourquoi les développeurs committent de façon quasi compulsive.

Pull request (ou « PR »)

Le morceau de choix. Une pull request, c’est la manière pour un développeur de dire : « J’ai modifié des choses. Quelqu’un peut relire avant que ça parte dans le vrai projet ? »

Concrètement, le développeur copie le code principal dans sa propre branche de travail, y fait ses modifications, puis ouvre une pull request. Celle-ci montre à ses collègues précisément quelles lignes ont été ajoutées, supprimées ou modifiées. Les collègues lisent, commentent (« ça risque de casser sur mobile », « joli correctif »), demandent des ajustements, et finissent par approuver. C’est seulement là que les changements sont intégrés au code principal.

En somme, c’est le « suivi des modifications avec validation » d’un document partagé, appliqué au code. Le nom est un peu à l’envers, il faut l’admettre : vous proposez des changements, mais techniquement vous demandez aux responsables du projet de tirer (« pull ») vos changements vers eux. L’histoire a ses raisons.

Merge

Le moment où les changements d’une pull request approuvée rejoignent le code principal. Quand deux personnes ont modifié les mêmes lignes différemment, on obtient un conflit de merge : le logiciel ne sait pas quelle version garder, alors un humain doit trancher. Cause majeure de soupirs chez les développeurs.

CI/CD

Derrière ce sigle, Continuous Integration / Continuous Delivery (ou Deployment), se cache une idée bien moins intimidante qu’elle en a l’air : des robots testent et livrent le code automatiquement.

L’intégration continue, c’est le volet tests. À chaque fois que quelqu’un pousse du nouveau code, un système automatisé construit le projet et fait tourner une batterie de tests. Quelque chose a cassé ? Tout compile encore ? La réponse tombe en quelques minutes, pas en quelques semaines. Un tapis roulant de contrôle qualité qui inspecte chaque changement à son arrivée.

La livraison continue, c’est le volet expédition. Une fois les tests passés, le code est empaqueté et publié automatiquement, parfois jusqu’aux vrais utilisateurs sans qu’aucun humain n’intervienne. C’est pour ça que les applications modernes se mettent à jour en permanence au lieu de sortir une grosse version par an. Des petits changements, testés automatiquement, livrés en continu.

Quand un développeur dit « la CI est rouge » ou « la CI échoue », comprenez : le robot inspecteur a rejeté les derniers changements, et rien ne part tant que ce n’est pas réparé.

Déployer

Déployer, c’est mettre le code en ligne, c’est-à-dire le faire passer de la machine du développeur aux serveurs que touchent les vrais utilisateurs. « On déploie vendredi à 17 h » est une phrase qui rend les ingénieurs expérimentés visiblement nerveux : si le déploiement casse quelque chose, le week-end de quelqu’un vient de s’évaporer.

API

Une API (Application Programming Interface) est le menu des services qu’un programme accepte de rendre aux autres programmes. Une appli météo ne possède pas de satellites : elle interroge l’API d’un service météo (« donne-moi les prévisions pour Lyon ») et reçoit des données structurées en retour. Les API sont la façon dont tout l’internet moderne se parle à lui-même. Et oui, c’est en général là que les tokens entrent en scène : l’API vérifie votre token avant de répondre, comme un videur vérifie votre bracelet.

Bug, debug et « ça marche sur ma machine »

Un bug est un défaut qui fait dérailler un logiciel. Déboguer, c’est le travail de détective qui consiste à le trouver et le corriger. Quant à « ça marche sur ma machine », c’est la défense éternelle du développeur dont le code tourne parfaitement sur son ordinateur portable mais casse partout ailleurs, généralement à cause d’une différence de configuration invisible. La moitié de l’outillage moderne, CI/CD comprise, existe précisément pour tuer cette excuse.

On assemble le tout

Voici une phrase que vous savez désormais décoder : « J’ai poussé un commit sur ma branche, ouvert une PR, la CI est passée, ça a été mergé et on a déployé. Mais les tokens de l’API ont expiré, donc on débogue. »

Traduction : j’ai enregistré mes modifications, demandé une relecture, les tests automatiques ont validé, mes collègues aussi, on a publié pour les utilisateurs. Puis nos clés numériques ont cessé de fonctionner et on cherche maintenant le problème.

Rien de magique là-dedans. Un processus de relecture, un tapis roulant de tests, quelques cartes magnétiques et beaucoup d’instantanés sauvegardés. Le vocabulaire fait barrage, mais les idées derrière, vous les connaissez déjà de la vie de tous les jours. La prochaine fois qu’un ingénieur vous dira que la CI est rouge et que le déploiement est bloqué, vous saurez exactement pourquoi il lui faut un deuxième café.