Mon CV en TOML

Les crochets m’ont toujours chagriné en TOML : je ne sais jamais ce que désignent exactement les simple et double crochets.

Ah haa

Certes, la structure est triviale, mais en YAML — qui aurait pu peut-être être aussi lisible — j’aurais été capable de mettre la mauvaise indentation quelque part, cassant ainsi la cohérence du document.

J’avais parfois le souci avec le langage Python et ce que j’en ai retenu, c’est qu’il faut surtout avoir un bon éditeur (et bien configuré) …avec de bonnes capacités de pliage et de navigation dans ce type de structure.
En me basant sur le JSON du billet, voici ce que cela donne (je laisse chacun juger pour la lisibilité) :

---
title: "Sgble's Curriculum Vitae "
lang: "en"
me:
  name: "Sgble"
  location: "Paris, FR"
  about: "I don't know what to say, I'm shy!"
  email: "sgble@example.com"
  github: "@sgble-example"
jobs:
  - title: "Benevolent Chairman for Life"
    company: "Sgble Corp"
    type: "self-employed"
    start: 2012-02-01
    location: "Paris, FR"
    desc: "I founded Sgble Corp to solve great challenges for the next decades!"
    tech: ["Office 360", "Rolodex", "MyOpenConciergerie"]
  - title: "Software Analyst & Architect (not Developer)"
    company: "Yet Another Tech Company"
    type: "full-time"
    start: 2010-07-03
    end: 2012-02-01
    location: "Paris, FR"
    desc: "Helped write code for the flagship product."
    tech:
      - "Python"
      - "Go"
      - "Kubernetes"
      - "Redis"
      - "PostgreSQL"
skills:
  tech:
    - skill: "Python"
      level: "Advanced"
    - skill: "Go"
      level: "Intermediate"
  other:
    - skill: "Accounting"
      level: "Intermediate"
    - skill: "Project Management"
      level: "Advanced"
"spoken-languages":
  - lang: "fr_FR"
    level: "Native"
  - lang: "en_US"
    level: "Somewhat okay"
  - lang: "fr_BE"
    level: "Elementary"

À titre strictement personnel — et ça n’engage que moi —, je trouve les deux versions (YAML et TOML) toute aussi lisibles. Ce le serait encore plus en utilisant la notation avec des tirets pour toutes les listes, mais j’imagine que tu es passé par un convertisseur automatique qui ne l’applique que lorsque la ligne devient trop longue.

La hiérarchie de la version YAML saute immédiatement aux yeux, alors qu’il faut connaître la signification des crochets simples et doubles en TOML — bien qu’on puisse se passer de le connaître ici en les lisant simplement comme des titres. Par contre c’est plus profond en YAML, et on y voit des détails techniques parasites, tel les guillemets autour de certaines clefs. Le TOML de @sgble est plus aéré et commenté, mais je ne prends pas en compte ce point car celui de @Gil Cot pourrait tout autant l’être — il a fait le choix de ne pas le faire.

Je seconde le point ayez un bon éditeur. Je suis certain que j’aurais pu écrire le YAML d’une traite sans erreur, car j’ai un bon éditeur (JetBrains 🧡) qui fait la moitié du boulot. De fait, il m’arrive d’écrire des YAML (ou JSON) à la main (principalement pour des tests ou pour rédiger des fichiers de configuration) sans que cela pose de problème (sinon une faute de frappe immédiatement rougie par l’éditeur et corrigée dans l’instant).

J’ai d’ailleurs écrit beaucoup de YAML à la main il fut un temps car c’est le format de configuration et stockage pour environ tout dans l’environnement de Bukkit/Spigot, pour lequel j’ai pas mal développé, y compris certaines choses assez avancées (dont des interfaces developer-friendly avec YAML, justement).

Les CV d’exemples sont incroyables. Ils en justifient la lecture à eux seuls. ✨

La hiérarchie de la version YAML saute immédiatement aux yeux, alors qu’il faut connaître la signification des crochets simples et doubles en TOML — bien qu’on puisse se passer de le connaître ici en les lisant simplement comme des titres. Par contre c’est plus profond en YAML, et on y voit des détails techniques parasites, tel les guillemets autour de certaines clefs. Le TOML de @sgble est plus aéré et commenté, mais je ne prends pas en compte ce point car celui de @Gil Cot pourrait tout autant l’être — il a fait le choix de ne pas le faire.

Pour la hiérarchie, en effet c’est un des bons points et aussi un inconvénient quand on a un fichier très long avec beaucoup d’entrées (c’est là que des marqueurs ou la fonctionnalité de pliage peuvent être utiles.)
Comme je suis parti du JSON, qui est sans commentaire, bah ils y sont pas (je n’ai juste pas pensé à les rajouter.) Pour les guillemets, j’ai laissé le dernier pour montrer que les clefs peuvent être comme en JSON, et je les ai viré pour les autres pour montrer qu’on peut faire comme en TOML. En vrai, c’est requis quand il y a des caractères perturbateurs (comme une clé qui comporterait un deux-point…)

Ce le serait encore plus en utilisant la notation avec des tirets pour toutes les listes, mais j’imagine que tu es passé par un convertisseur automatique qui ne l’applique que lorsque la ligne devient trop longue.

Non, entièrement fait à la main. J’ai laissé ce cas exprès pour montrer que c’est possible aussi (en fait comme c’est un surensemble de JSON, ce genre de constructions est permise et courante même si perso je n’aime pas trop) tout comme on avait la forme non compacte dans l’exemple fictif

tech = [
  "TVM 700",
  "ETCS Level 6",
  "Ubuntu for Rails",
  "ERTMS-NG",
]

Dans la même veine, on aurait pu avoir aussi

skills:
  tech:
    - { skill: "Python", level: "Advanced" }
    - { skill: "Go", level: "Intermediate" }
  other: [ { skill: "Accounting", level: "Intermediate"}, { skill: "Project Management", level: "Advanced"} ]

…où on voit que le JSON incorporé est plus relax aussi.

Le seul truc qu’il manquait, c’est l’illustration d’un texte long (toujours dans l’exemple fictif.)

Je comprends pas le principe.
Au final, tu va envoyé le toml à un recruteur ?

On est d’accord que c’est juste pour le fun ?

Oui et non. Mon CV actuel (traditionnel : LaTeX rendu en PDF) n’est plus à jour et est donc inutilisable. J’ai refait rapidement une version à jour en TOML, et à ce jour c’est la seule version valide que j’utiliserais si l’occasion se présente.

Je précise que je ne recherche pas d’emploi. Même hors processus de recrutement, un CV peut m’être demandé en de rares occurrences, mais soyons honnêtes : dans ces cas spécifiques ça sera pour la forme, personne ne le lira. Par exemple pour certains trucs administratifs, des demandes de subventions, etc.

Mais quand même je serais en recherche d’emploi, un CV en TOML serait certes surprenant, mais non disqualifiant je pense, compte tenu du type de jobs auxquels je postulerais (dans la tech). Ça ne serait pas plus choquant que le CV de certains designers ou autre métier artistique.

Si quelqu’un donne son CV en TOML (ou au moins le texte TOML joliment coloré syntaxiquement sur un PDF), je veux bien son retour d’expérience, ça m’intéresserait de savoir. Ou bien si vous avez en charge le recrutement (plutôt tech) dans votre entreprise, ça m’intéresse de savoir ce que vous penseriez d’un tel CV. Je ne verrais pas de problème, personnellement, tant que j’y trouve les infos que je cherche.

Ouais, la première fois que j’ai vu ça en TOML j’ai trouvé ça un peu curieux. Je suppose qu’avec l’équivalent donné en JSON tu peux faire le mapping et voir la différence. Mais effectivement, c’est pas évident.

Bizarrement, malgré ça je pense que le TOML serait potentiellement plus compréhensible par une personne non technique. Elle ne ferait peut-être pas le bon mapping, mais qu’importe, les données sont présentées « à plat » d’une façon plutôt habituelle, elle trouverait les informations sans se demander le pourquoi du comment de l’indentation. Le YAML donné en exemple plus haut est lisible aussi, mais peut-être plutôt par des personnes techniques qui ont l’habitude de voir une hiérarchie dans les indentations.

Poru répondre à ta question sur la perception d’un tel CV : pour moi ça n’est intéressant que dans une toute petite entreprise, ou une entreprise pour laquelle tu es certain que tous les décideurs du recrutement sont techniques. Parce que ça va amuser des personnes techniques (sans donner de vrai plus si tu veux mon avis, les CV sont déjà très variés sur leurs formes) mais perturber les autres. Le contenu est de très loin le plus important, les seuls buts de la forme sont d’être lisibles et d’éviter les grosses fautes de goût (comme ce candidat dont la photo de CV était une photo de vacances de luxe).

D’autre part tu seras sans doute obligé de le formater sur deux colonnes pour réussir à le faire tenir sur une page avec une taille de caractère raisonnable.

Poru répondre à ta question sur la perception d’un tel CV : pour moi ça n’est intéressant que dans une toute petite entreprise, ou une entreprise pour laquelle tu es certain que tous les décideurs du recrutement sont techniques.

Ça va alors, typiquement le seul genre de boîte où je pouvais bosser

Si je me trouve dans une entreprise telle que tu as décrite, je ne suis pas sûr que ce soit un souci. Le CV restera sûrement consulté sur éditeur de texte uniquement, jamais imprimé ni mis sous autre forme etc.

Avoir le CV imprimé sur une page pour les premiers entretiens, c’est super pratique. D’où ma réflexion.

Ah oui, j’avais oublié qu’on faisait ça. Effectivement. Après, sans me vanter, mon CV « conventionnel » ne tient pas non plus en une page malgré les sections Education et Hobbies omises, héhé. Mais contrairement à la nouvelle version TOML, je m’étais forcé à bien broder pour chaque description de poste, ce qui finit par étoffer le document plus vite qu’on ne le pense.

Pour moi l’exercice du CV en une page (à la française, c’est assez spécifique à la France) revient à dire : qu’est ce qui est le plus important à présenter pour que, d’un coup d’œil, le recruteur de ce poste ait envie d’en savoir plus et de m’embaucher ?

Ça implique que quelqu’un d’expérimenté aura sans doute un CV complet en plusieurs pages, et un CV d’une page par entreprise sollicitée, et que ce CV d’une page aura des points non détaillés voire des trous.

Après tu l’imprimes depuis ton éditeur de texte, en choisissant un thème de couleurs qui va bien (et hop ça le rend plus sexy), et en précisant dans les options que tu veux mettre deux pages par face de feuille (et hop ça te fait ta double colonne) Le seul souci est donc les personnes non techniques en face qui sauront pas faire ces manips. Après, si tu mets ton CV en ligne, tu peux (comme les gens qui explorent le format HTML —j’avais vu une discussion passer sur ce sujet sur LinuxFr) t’assurer de régler ces soucis en amont via CSS ?

Je crois qu’il y a le même exercice dans le monde anglo-saxon. Ils distinguent deux documents : l’un s’appelle résumé, l’autre CV, mais je ne sais plus lequel est censé être la version courte qui tient sur une page ou presque.

Dans tous les cas, je ne pense pas que cela ait eu une grande importance aux yeux des entreprises avec lesquelles j’ai interagi lors des recrutement. Peut-être que les formes et les conventions ont beaucoup plus d’importance dans d’autres secteurs ou d’autres types d’entreprise.

Et un CV ce n’est pas qu’un document de candidat qui cherche un job, et qui sera lu que par des recruteurs. C’est plus général, c’est pour n’importe qui ayant un intérêt à découvrir le parcours d’une personne. Cela explique aussi sans doute que je fasse un CV qui n’entre pas autant dans les détails sur les expériences professionnelles. Je n’ai plus de raison de le faire, je reste sur quelque chose de plus générique dans les descriptions (à défaut d’être générique sur le format :-°).

Après, si tu mets ton CV en ligne, tu peux (comme les gens qui explorent le format HTML —j’avais vu une discussion passer sur ce sujet sur LinuxFr) t’assurer de régler ces soucis en amont via CSS ?

Si je fais ça, ça sera implicitement une ligne dans mon CV qui dit : « nul en CSS et en Web front en général »

Les CV d’exemples sont incroyables. Ils en justifient la lecture à eux seuls. ✨

Moi ce que j’aime dans le cv de sgble c’est sa parfaite adéquation avec les RH qui ont besoin de quelqu’un qui a plus de 10 ans d’XP avec Kubernetes (qui n’a que 8ans). Et ça c’est un plaisir de gourmet.

@sgble Au pire, il te reste alors que le PDF (imprimer dans un fichier et non sur papier) comme avant

@artragis Le fameux mouton à six pattes si tu rajoutes que la personne vient d’avoir son doctorat et a une expérience significative en entreprise. Ah les spider-profiles…

Alors il se trouve que j’avais une autre version du CV avec une section Education assez surprenante. Il n’y avait pas qu’un seul PhD

Article intéressant.

À noter qu’en JSON, il existe une solution structurée permettant de gérer son CV, et d’en générer une page HTML ou un PDF : https://jsonresume.org

Il disposent notamment d’intégrations dans des services tiers.

C’est intéressant. Justement, je m’étais demandé s’il n’existait pas une spécification JSON-LD pour les CV ou les résumés, dans le même genre.

Voici donc le CV TOML, en version iso avec le format JSON Resumé.

Certains éléments sont pensés différemment, ou absents : il n’y a pas d’idée de titre ou de langue globale du CV — j’imagine qu’il est considéré que ces deux éléments peuvent être inférés du texte lu, et des clefs basics.name et basics.label (absente ci-dessous car il n’y avait pas d’équivalent dans le CV TOML de @sgble).

Par contre, possiblement car le format est plus générique, il n’y a pas d’équivalent de jobs[].tech au profit d’une liste plus générique highlights. Il n’y a pas non plus de sous-catégories pour les compétences (skills), mais une liste de mots-clefs est proposée.

[basics]
name = "Sgble"
email = "sgble@example.com"
summary = "I don't know what to say, I'm shy!"
location = { city = "Paris", countryCode = "FR" }

[[basics.profiles]]
network = "GitHub"
username = "sgble-example"
url = "https://github.com/sgble-example"


### Work Experience

[[work]]
name = "Sgble Corp"
position = "Benevolent Chairman for Life"
location = "Paris, FR"
startDate = 2012-02-01
summary = "I founded Sgble Corp to solve great challenges for the next decades!"
highlights = [
    "Self-employed",
    "Office365",
    "Rolodex",
    "MyOpenConciergerie"
]
# Ces deux là ne sont pas dans le standard ; à lire, il me semble qu'il est
# attendu que ce soit intégré à summary ou highlights.
# type = "self-employed"
# tech = ["Office 360", "Rolodex", "MyOpenConciergerie"]


[[work]]
name = "Yet Another Tech Company"
position = "Software Analyst & Architect (not Developer)"
location = "Paris, FR"
startDate = 2010-07-03
endDate = 2012-02-01
summary = "Helped write code for the flagship product."
highlights = [
    "Full-time job",
    "Managed a huge Kubernetes cluster",
    "Python",
    "Go",
    "Kubernetes",
    "Redis",
    "PostgreSQL"
]
# De même que plus haut pour ces deux là.
# type = "full-time"
# tech = ["Python", "Go", "Kubernetes", "Redis", "PostgreSQL"]


### Tech skills

[[skills]]
name = "Python"
level = "Master"
keywords = [
    "tech",
    "metaclasses",
    "pattern matching",
    "a snake can hide another"
]

[[skills]]
name = "Go"
level = "Intermediate"
keywords = ["tech"]


### Other skills

[[skills]]
name = "Accounting"
level = "Intermediate"

[[skills]]
name = "Project Management"
level = "Master"


### Spoken languages

[[languages]]
language = "fr_FR"
fluency = "Native"

[[languages]]
language = "en_US"
fluency = "Somewhat okay"

[[languages]]
language = "fr_BE"
fluency = "Elementary"

Il y a beaucoup d’autres catégories proposées dans le JSONResumé, nommément :

• volunteer (pour quand vous travaillez bénévolement car vous êtes gentil·le (sauf si c’est du bénévolat pour des assos d’extrême droite)) ;
• education (quand vous dites que vous étudiez alors qu’en vrai vous passez votre temps dehors) ;
• awards (quand vous gagnez des coupes toutes lustrées) ;
• certificates (re-études mais quand on est adulte et nostalgique des diplômes) ;
• publications (non pas les bêtises de LinkedIn svp) ;
• interests (c’est le moment de dire que les papillons de nuit sont votre passion) ;
• references (si des gens vous font confiance) ;
• projects (pour raconter tout ce que vous avez commencé sans jamais le finir) ;
• et meta (pas pour Facebook, mais pour préciser l’URL canonique du CV, sa version, sa date de dernière modification, et d’autres trucs non-standards si vous le jugez pertinent).

C’est beaucoup plus fin, oui. Mais j’ai peur de perdre le côté lisible tel quel en tant qu’humain qui ne connaît pas forcément le TOML, surtout pour les infos du [me] qui étaient simplement mises en vrac comme la clé github par exemple. Pour le reste, ça ne semble pas changer grand chose, par contre.

Ce qui m’étonne beaucoup, c’est qu’avec tout ça on a oublié d’indiquer le plus important dans ces CV fictifs :

# ...
[[skills]]
name = "TOML"
level = "Alright"
keywords = ["tech", "c:"]
# ...

Je viens de retrouver, c’était un billet d’Andre Rodier en février 2021, et le premier commentaire mentionnait JSON Resume

Ça tombe bien, je vois qu’il y a, en plus du riche écosystème, des thèmes JSON Resume qui font le boulot pour vous. Eh non, suis pas actionnaire. Mais ça fait un an que je dois m’y mettre…

En effet, c’est dans la sphère francophone qu’on n’utilise qu’un seul mot pour désigner les deux… J’ai lancé une petite recherche dans un moteur. La plupart des liens sont en anglais car c’est une distinction qu’on trouve surtout dans le monde anglo-saxon. En français, j’ai cv.fr qui dit que :

• resume c’est le fameux CV qui doit tenir sur une page, donc concis et dynamique et adapté selon chaque poste/candidature.
• cv c’est quand ça fait roman exhaustif de forme statique, et en Amérique du nord c’est surtout utilisé dans les milieux universitaires/scientifiques/recherche.

cv.modelocurriculum.net va dans le même sens en indiquant que le résumé « est conçu pour mettre en évidence vos principales qualités, vos forces qui sont en rapport direct avec le poste auquel vous postulez. » et que les « recruteurs préfèrent normalement le CV pour des postes qui exigent des études supérieures (scientifiques, chercheurs, docteurs, professeurs, ingénieurs…), car il a tendance à être plus compréhensible et plus général. »

Toujours en français, ma recherche m’a mené sur genius-cv.com qui indique que dans la conception, « Un CV est un document narratif tandis qu’un resume est un document marketing. »