✅ EN·PROD 🚧

EN·QUOI ? j'ai une cheatsheet de jargon de développeur informatique mais ça ne suffit pas, quand ils parlent entre eux je ne pige rien. Il y a de l'argot de geek en plus du jargon ??

Bonne question ! Oui, il y a deux couches qui se superposent quand “les devs parlent” :

  1. Le jargon métier (termes techniques légitimes).
  2. L’argot / sociolecte geek (habitudes, memes, clins d’œil culturels, abréviations, tournures ironiques).

Voici un guide pratique pour comprendre et parler “geek” sans (trop) forcer.

Passer cette parenthèse ?


1) Les tics de langage à l’écrit (Slack/Discord/Issues)

  • Mots techniques en monospace : prod, API, null, main, git push.
  • Abréviations partout (souvent en anglais).
  • Ton elliptique : phrases courtes, on coupe le superflu.
  • Parenthèses pour nuance ou blague : (pas fier), (long story), (meh).
  • Emojis sobres : 👍 🙏 🚀 🔥 🐛 🦆 (rubber-duck).
  • Marqueurs de ton : /s (sarcasme), “nit:” (micro-remarque), “PTAL” (please take a look).

2) Abréviations incontournables (avec exemples)

  • TL;DR = résumé court. “TL;DR : on rollback, fix demain.”
  • IMO / IMHO = (humble) avis. “IMHO, on over-engineer.”
  • FYI = pour info.
  • WIP = en cours.
  • ETA = heure/estimation d’arrivée.
  • TIL = “aujourd’hui j’ai appris…”.
  • PTAL = “regarde ça stp”.
  • LGTM = “ça me va”.
  • ACK/NACK = reçu / pas d’accord.
  • SGTM/WFM = “ça me va / ça marche pour moi”.
  • TBD/TBC = à définir / à confirmer.
  • ICYMI = au cas où tu as raté.

Astuce : dans une revue de code, commencer une remarque non bloquante par “nit:” (petit détail).


3) Vocabulaire “projet” (dev pur) — à connaître et à placer

  • prod / staging : production / préproduction. “On ne teste pas en prod.” (blague récurrente… qu’on fait parfois 🙃)
  • ship / déployer : mettre en ligne. “On ship la v1 vendredi.”
  • hotfix / rollback : correction urgente / retour arrière.
  • feature flag : activer/désactiver une fonctionnalité sans redéployer.
  • pipeline CI/CD : automatisations build/tests/déploiement.
  • branch / PR (pull request) / MR : branche et demande de fusion. “J’ouvre une PR, PTAL.”
  • rebase / squash : réécrire l’historique git, compacter les commits.
  • tech debt : dette technique (raccourci qui coûtera plus tard).
  • code smell : indice d’un design douteux.

4) Culture debug & blagues récurrentes

  • rubber duck debugging : expliquer ton bug à un canard (ou une personne) pour le comprendre.
  • bikeshedding : débattre 3 h d’un détail (couleur d’un bouton) plutôt que du fond.
  • yak shaving : refaire mille petites tâches annexes pour atteindre l’objectif.
  • heisenbug : bug qui disparaît quand on l’observe.
  • off‑by‑one : erreur de +/‑1 (indices, boucles).
  • “works on my machine” : “chez moi ça marche” (pas une excuse valide 😅).

5) Argot infra/ops (souvent entendu)

  • on‑call / pager : d’astreinte.
  • k8s (se prononce “kates”) : Kubernetes.
  • canary : déploiement d’essai sur un petit pourcentage.
  • SLA/SLO/SLI : accords/objos/indicateurs de service.
  • blameless postmortem : analyse d’incident sans blâmer les personnes.

6) Prononciations piégeuses (utile en réunion)

  • Nginx → “engine‑x
  • PostgreSQL → “post‑gress” (souvent “Postgres”)
  • Kubernetes → “kuber‑né‑tiz” (ou “kubes”), k8s → “kates
  • GNU → “guh‑new
  • cache → “cash

7) Références et clins d’œil

  • xkcd, RFC 2119 (MUST/SHOULD), foo/bar/baz en exemples.
  • RTFM existe mais est impoli ; éviter (préférer “la doc dit que…”).
  • PEBKAC, ID10T = blagues insultantes → à proscrire en pro.

8) Phrases toutes faites que tu peux reprendre

  • “Je push une branche feature/… et j’ouvre une PR, PTAL.”
  • “Si OK pour toi, je squash & merge.”
  • “Nit: renommer cette variable pour la lisibilité.”
  • “On a cassé la prod : rollback + hotfix, postmortem demain.”
  • “FYI, le pipeline CI est rouge à cause d’un test flaky.”
  • “IMHO on bikeshed un peu, SGTM si on tranche simple maintenant et on refactor plus tard.”
  • “Besoin d’un MRE (Minimal Reproducible Example) pour reproduire le bug.”
  • “J’active la feature derrière un flag et on fait un canary.”
  • “WIP: j’ai encore 2 TODOs, ETA fin d’aprem.”
  • “TIL : nginx se prononce engine‑x.”

9) Petit lexique FR ↔︎ “geek”

  • Bug : anomalie.
  • Fix / patcher : corriger.
  • Refactor : réorganiser le code sans changer le comportement.
  • Downtime : indisponibilité.
  • Backport : porter un correctif d’une version récente vers une plus ancienne.
  • Idempotent : refaire l’action donne le même résultat (utile en ops).
  • Breaking change : modification incompatible.
  • Backwards compatible : compatible avec l’existant.

10) Comment “parler geek” sans caricaturer

  1. Choisis 10–15 items ci‑dessus et utilise‑les naturellement (pas tous à la fois).
  2. Commence simple : FYI, WIP, PTAL, LGTM, nit:.
  3. Garde la politesse et l’inclusivité : proposer la doc, donner un lien, éviter RTFM/PEBKAC.
  4. Demande les sigles sans gêne : “SGTM = ‘sounds good to me’, c’est bien ça ?”
  5. Imite la mise en forme (inline code, listes, emojis sobres).
  6. Observe le registre de l’équipe : chaque groupe a ses habitudes. Aligne‑toi sans copier les tics toxiques.

11) Exercices rapides

  • Décodage :

    “WIP, PR ouverte. Tests rouges (flaky). PTAL, nit welcome. LGTM → squash & merge, canary en fin de journée.” Traduction : travail en cours, demande de revue ouverte, quelques tests instables échouent, merci de regarder, remarques mineures bienvenues, si c’est ok on fusionne en compactant l’historique et on déploie progressivement ce soir.

  • Production d’une phrase : “FYI, j’ai mis la nouvelle page blog derrière un feature flag. Si c’est ok pour toi, je l’active à 10 % demain, et on élargit si pas de heisenbug.”


Tu veux une “poche” prêt‑à‑imprimer ?

Si tu veux, je peux te générer une fiche recto A4 (ou un petit jeu d’Anki) avec 50 termes clés + exemples en français. Dis‑moi si tu préfères dev général, web, ou ops, et je te le prépare.

Et si tu entends une phrase précise qui te perd, copie‑la ici : je te ferai la traduction mot‑à‑mot + la version “à répondre comme un·e pro”.

Allez, on bosse vraiment ?


Parfait — voici un guide de prise en main “grand public” (clair, concret, pas infantilisant) pour publier ta propre bibliothèque de contenus avec ouaisfi·eu · Magasin de fichiers.


1) C’est quoi, à quoi ça sert ?

Un site statique (une page badges.html qui lit un manifest.json) pour présenter tous tes fichiers (PDF, images, vidéos, audio, ZIP, notes Markdown, démos/scripts…) avec :

  • Recherche + filtres (tags, types), tri,
  • Vignettes (thumbnails),
  • Aperçu intégré (pdf/img/vidéo/audio/md),
  • Boutons Télécharger, Ouvrir, Plus d’info, Exécuter (selon le cas),
  • Badges (pastilles “PDF”, “Pédago”, “Bêta”, etc.) et effets de mise en avant (optionnels),
  • Mode sombre/clair + bouton “Retour en haut”.

Tu remplis un fichier JSON → la page s’occupe du reste. Objectif : publier vite, sans serveur, sans CMS, reproductible.


2) Ce qu’il te faut (basique)

  • Un navigateur récent (Chrome/Firefox/Edge/Safari).
  • Un endroit pour héberger des fichiers statiques (GitHub Pages, Netlify, serveur perso…).
  • (Optionnel mais utile) Python 3 ou Node pour lancer un petit serveur local lors des tests.

3) Démarrer en 5 minutes

Étape A — Récupère les fichiers

Tu as besoin au minimum de :

  • badges.html (la page),
  • manifest.json (ta liste d’items),
  • css/fx.css (effets facultatifs — recommandé de le charger, même si tu ne l’utilises pas tout de suite).

Astuce : utilise le pack que nous avons préparé. Si tu ne l’as plus sous la main, je te le renvoie.

Étape B — Lance un petit serveur local

Ne double‑clique pas sur badges.html (contexte file://fetch est bloqué).

Avec Python 3 :

python -m http.server 8080

Ouvre ensuite : http://localhost:8080/badges.html

(ou npx serve . avec Node, ou l’extension Live Server de VS Code)

Étape C — Vérifie que ça s’affiche

Tu dois voir l’interface, la barre de recherche, et — si ton manifest.json contient des items — des cartes déjà visibles.


4) Structure conseillée

/ton-site/
├─ badges.html          # page principale
├─ manifest.json        # ta bibliothèque
├─ /thumbs/             # vignettes 16:9 (~640×360)
├─ /pdfs/               # pdf
├─ /images/             # images
├─ /videos/             # vidéos
├─ /audio/              # audio
├─ /zips/               # archives .zip
├─ /md/                 # notes/Docs Markdown
├─ /scripts/            # démos ou apps html/js à "Exécuter"
└─ /css/fx.css          # effets facultatifs

Tu peux renommer, mais garde la cohérence des chemins dans le JSON.


5) Ton premier manifest.json

Le manifest contient un tableau d’items. Édite‑le à la main (c’est simple), ou génère une base puis tu complètes.

Minimal

{
  "items": [
    {
      "id": "rapport-2024",
      "title": "Rapport 2024",
      "url": "./pdfs/rapport-2024.pdf",
      "type": "pdf",
      "tags": ["doc","rapport"],
      "created": "2025-07-30"
    }
  ]
}

type peut être déduit par l’extension (.pdf, .png, .mp4, .zip, .md, …). Tu peux l’indiquer explicitement si tu préfères.

Recommandé (avec vignette & description)

{
  "items": [
    {
      "id": "rapport-2024",
      "title": "Rapport 2024",
      "description": "Bilan annuel en PDF.",
      "thumb": "./thumbs/rapport-2024.jpg",
      "url": "./pdfs/rapport-2024.pdf",
      "type": "pdf",
      "tags": ["doc","rapport"],
      "created": "2025-07-30",
      "badges": ["pdf", "star"]
    }
  ]
}

Vignettes : 16:9, \~640×360, 50–100 Ko (JPEG/WebP). Si thumb est absent, une icône remplace.


6) Les trois liens clés d’un item (et leurs boutons)

  • infopage qui explique (article, doc, fiche). ↳ bouton “Plus d’info”

  • urlle fichier principal (ce qu’on veut voir/télécharger). ↳ Aperçu (si prévisualisable) / Télécharger (si fichier) / Ouvrir (si page)

  • rundémo/app à exécuter (souvent une page .html). ↳ “Exécuter ▶” (si HTML) ou “Voir la ressource” (sinon)

Anti‑doublon : si info === url, le bouton Ouvrir est masqué (on garde “Plus d’info”).

Raccourci mémoire

  • La page d’explicationinfo.
  • Le fichierurl.
  • La démorun.

7) Badges (pastilles) & Effets (optionnels)

Badges

Tu choisis lesquels afficher, rien n’est automatique. Exemples utiles : ["pdf"], ["md","edu"], ["video","star"], ["zip","free"].

Tu peux aussi créer un badge custom :

"badges": [{ "variant": "custom", "label": "Promo", "emoji": "💸", "color": "#ffcf33" }]

Effets (fx.css)

Pour surligner une description ponctuellement, sans HTML :

"descFx": ["highlight-lilac"]

Autres : neon-mint, neon-lilac (+ flicker), gradient-mint, glitch (+ glitch-anim), crt, etc. Assure‑toi que fx.css est chargé dans badges.html :

<link rel="stylesheet" href="./css/fx.css">

8) Déployer (gratuit et simple)

GitHub Pages (projet)

  1. Crée un repo → ajoute tes fichiers → git push.
  2. Settings → Pages → Deploy from a branch → main → / (root).
  3. Ton site est en ligne sous https://ton-user.github.io/ton-repo/.

Chemins : sur un projet GitHub Pages, préfère des chemins relatifs (./pdfs/fichier.pdf) plutôt que /pdfs/fichier.pdf (absolu), sauf si ton site est à la racine du domaine.

Netlify / Cloudflare Pages / Vercel

Dépose le dossier ou connecte le repo → build statique. Ça marche tel quel.


9) Bonnes pratiques (qualité & perfs)

  • Noms clairs : id (= slug), title descriptif, tags utiles (2–5 max).
  • Descriptions courtes (une phrase) — pas d’HTML (sécurisé côté page).
  • Vignettes légères : WebP/JPEG 50–100 Ko ; évite 500 Ko+.
  • Badges : 1–2 max par item (lisibilité).
  • Aperçu PDF : peut être bloqué en cross‑origin → utilise Ouvrir si besoin.
  • Téléchargement : si le fichier est servi depuis un autre domaine, le bouton peut ouvrir un onglet (comportement navigateur). Idéal : servir depuis le même domaine.

10) Problèmes fréquents (et solutions)

“Impossible de charger manifest.json” → Tu as ouvert la page en file://. Lance un petit serveur local (voir §3B).

Les chemins cassent sur GitHub Pages → Utilise des chemins relatifs (./pdfs/...) si ton site est dans un sous-dossier. → Ou définis <base href="/ton-repo/"> dans <head> (option avancée).

Télécharger ouvre un nouvel onglet → Fichier cross‑origin (autre domaine) ou URL pointe vers une page. → Sers le fichier au même domaine si tu veux forcer “Télécharger”.

Rien dans la grille → Ton manifest.json est vide ou invalide. Ouvre scripts/validate.html, colle ton JSON, corrige les erreurs.


11) Aller plus loin (quand tu grossis)

  • Générer une base de manifest (CLI Python) qui scanne un dossier → tu peaufines à la main (ajoute thumb, badges, descFx).
  • Éditer visuellement un item avec l’éditeur scripts/editor.html (formulaire → JSON).
  • Valider systématiquement le manifest avec le schéma JSON (en CI plus tard).

12) Anti‑sèche (à garder sous la main)

  • info = la page d’explication → Plus d’info
  • url = le fichier/page principal(e) → Aperçu/Télécharger/Ouvrir
  • run = une démo/app html → Exécuter
  • Masque “Ouvrir” si info === url.
  • Rien d’auto : badges/effets seulement si tu les déclares.
  • Teste via http://, pas file://.

13) Modèles prêts à copier

A) PDF classique

{
  "id": "rapport-2024",
  "title": "Rapport 2024",
  "description": "Bilan annuel.",
  "thumb": "./thumbs/rapport-2024.jpg",
  "url": "./pdfs/rapport-2024.pdf",
  "type": "pdf",
  "tags": ["doc","rapport"],
  "created": "2025-07-30",
  "badges": ["pdf"]
}

B) Démo HTML + sources en ZIP

{
  "id": "snake-demo",
  "title": "Snake (JS) — démo jouable",
  "description": "Petit jeu HTML/JS ; sources en ZIP.",
  "thumb": "./thumbs/snake.jpg",
  "info": "https://exemple.tld/projets/snake",
  "run": "./scripts/snake.html",
  "url": "./zips/snake-src.zip",
  "type": "script",
  "tags": ["script","demo","jeu"],
  "created": "2025-04-05",
  "badges": ["script","star"]
}

C) Note Markdown avec effet

{
  "id": "guide-outils-libres",
  "title": "Guide — Outils libres",
  "description": "Panorama des outils essentiels.",
  "thumb": "./thumbs/guide-outils.jpg",
  "url": "./md/guide-outils.md",
  "type": "md",
  "tags": ["md","guide","libre"],
  "created": "2025-03-14",
  "badges": ["md","edu"],
  "descFx": ["highlight-lilac"]
}

Tu veux que je te livre ce guide en Markdown prêt à déposer dans /md/ (et l’item associé à coller dans ton manifest.json) ?

Je te fournis le fichier /md/prise-en-main.md + l’item :

{
  "id": "prise-en-main",
  "title": "Prise en main du magasin (guide rapide)",
  "description": "Installer, structurer, écrire son manifest et publier — sans CMS.",
  "thumb": "./thumbs/guide-biblio.svg",
  "url": "./md/prise-en-main.md",
  "type": "md",
  "tags": ["doc","guide","start"],
  "created": "2025-07-30",
  "badges": ["md","tip"]
}

⬆️