Licence CC BY-SA

Mon CV en TOML

cv.toml

J’ai décidé de rédiger mon nouveau CV en TOML.

Il s’agissait au début d’une blague, mais après réflexion j’ai voulu tester et rédiger sérieusement mon nouveau CV en TOML, en essayant d’utiliser au mieux ce que le langage propose sémantiquement et syntaxiquement. Le langage TOML se prévaut d’être un langage aussi bien facile à écrire qu’à lire pour l’humain, en plus de l’être pour la machine. Naturellement, il faut donc que ce CV soit distribuable et lisible par les humains tel quel, c’est à dire en TOML brut.

Écrire un cv.toml

Comme n’importe quel document, ce CV a un titre. Et comme n’importe quel CV, on va commencer par se présenter avec diverses métadonnées jugées pertinentes selon le profil.

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"

Poursuivons avec l’expérience professionnelle. Voici la structure que j’ai choisie, elle reprend les attributs classiques que l’on retrouve dans un CV. Pour les dates de début et de fin, start et end, on utilise le type natif de date de TOML.

# Work Experience

[[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"]


[[jobs]]
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"]

[[jobs]]
# ...
# ...

J’ai bien de la chance, peu de mes expériences sont dignes qu’on leur accorde plus de quelques mots dans le champ desc (description), faisant ainsi tenir leur description sur une ligne sous 80–100 caractères. Mais autrement, TOML aurait su gérer la situation avec des chaînes de caractères sur plusieurs lignes, ainsi que les tableaux sur plusieurs lignes, ce qui facilite la lisibilité humaine.

Exemple (fictif) d’une de mes expériences dans une autre vie :

[[jobs]]
title = "Conducteur de trains Maglev très haute vitesse"
company = "Société Nationale des LM de France"
type = "full-time"
start = 2038-02-01
end = 2042-08-01
location = "France & UE"
desc = """
  Conduite des eurotrains modèles MG-1 et MG-2/MG-2X (2500 pax) en France et
  en Europe. Conduite des vieux TGV M sur rails acier (polyvalence).
  
  Suivi et respect de la signalisation en cabine et sur voie (rigueur).
  
  Contribution à la propreté de la cabine avec la mise en place de corbeilles
  à papiers (force de proposition).
  
  Aide et accueil des passagers qui arrivaient en cabine pensant y trouver leur
  place (soft skills humains).
"""
tech = [
  "TVM 700",
  "ETCS Level 6",
  "Ubuntu for Rails",
  "ERTMS-NG",
]

Cela montre le principe général. Pour chaque type d’entrée, on a des champs à renseigner et le CV consiste surtout en une table de listes énumérant d’autres tables d’un même « type ». Voici des exemples de ce que l’on pourrait avoir comme autres types d’objets, ils parleront sûrement d’eux-mêmes.

# Spoken languages

[[spoken-languages]]
lang = "fr_FR"
level = "Native"

[[spoken-languages]]
lang = "en_US"
level = "Somewhat okay"

[[spoken-languages]]
lang = "fr_BE"
level = "Elementary"

# Skills

[[skills.tech]]
skill = "Python"
level = "Advanced"

[[skills.tech]]
skill = "Go"
level = "Intermediate"

[[skills.other]]
skill = "Accounting"
level = "Intermediate"

[[skills.other]]
skill = "Project Management"
level = "Advanced"

C’est assez confortable de pouvoir imbriquer « à plat » certaines catégories, ici skills.tech et skills.other.

Le document final paraît assez « plat », ce qui le rend agréable à lire humainement, mais en contrepartie cela laisse peu ressortir la structure sous-jacente. Le voici dans son intégralité, suivi du JSON équivalent pour mieux se faire une idée de la structure.

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"

# Work Experience

[[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"]


[[jobs]]
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"]

# Tech skills

[[skills.tech]]
skill = "Python"
level = "Advanced"

[[skills.tech]]
skill = "Go"
level = "Intermediate"

# Other skills

[[skills.other]]
skill = "Accounting"
level = "Intermediate"

[[skills.other]]
skill = "Project Management"
level = "Advanced"

# Spoken languages

[[spoken-languages]]
lang = "fr_FR"
level = "Native"

[[spoken-languages]]
lang = "en_US"
level = "Somewhat okay"

[[spoken-languages]]
lang = "fr_BE"
level = "Elementary"

Équivalent en JSON :

{
  "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"
    }
  ]
}

Conclusion

Personnellement j’aime bien mon CV en TOML. Mais il faut quand même admettre qu’un bon thème de coloration syntaxique ne sera pas un luxe pour en faciliter la lecture. Reconnaissons aussi que les commentaires — que TOML a le bon goût d’autoriser — contribuent aussi à la lisibilité en séparant les sections.

Le rédiger ne m’a posé aucun problème. 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. Quant à JSON ou XML, je n’aurais pas fait un document valide du premier coup.

Pour ce qui est de la lisibilité, je vous laisse en qualité de juges. Cependant, je vous invite à utiliser votre éditeur de texte favori pour juger, car le thème TOML de ZdS n’est peut-être pas celui qui le rendra le mieux.

Le saviez-vous ? La nouvelle version de Python 3.11 inclut tomllib dans sa bibliothèque standard, vous permettant ainsi de traiter des CV structurés en TOML automatiquement. Plus d’informations dans l’article d’entwanne.



23 commentaires

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"
+2 -0

À 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. ✨

+2 -0

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 ?

+0 -0

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 ?

ache

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.

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

SpaceFox

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.

+2 -0

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 :D

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.

SpaceFox

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.

+0 -0

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.

+0 -0

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) :D 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 ?

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.

SpaceFox

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 » :-°

+0 -0

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.

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

Le format présenté sur la version grand public du site est incomplet : certaines clefs autorisées par le schéma technique publié sur GitHub ne sont pas présentées, tel que work[].location.

Si vous savez lire un format JSONSchema, le leur est bien rédigé.

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).
+4 -0

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:"]
# ...
+1 -0

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 ?

Gil Cot

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

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 » :-°

sgble

Ç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. :D Mais ça fait un an que je dois m’y mettre…

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.

SpaceFox

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.

sgble

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. » <3

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte