Un portfolio développeur est un document HTML structuré qui expose des réalisations techniques à un recruteur ou un client potentiel. Sa valeur repose moins sur le design que sur la qualité du balisage sémantique et le choix des sections. Un fichier index.html bien structuré avec cinq ou six sections ciblées remplace avantageusement un template surchargé de scripts et d’animations.
Balisage sémantique HTML : la base technique du portfolio
Avant de choisir quelles sections inclure, la question porte sur le balisage. Un portfolio codé avec des <div> partout perd en accessibilité et en lisibilité pour les moteurs de recherche. Les balises HTML5 sémantiques changent la donne.
A lire également : Comprendre le trolling sur Internet : motivations et impacts des trolls
La balise <header> encapsule le nom, le titre professionnel et la navigation. La balise <main> contient le corps du portfolio. Chaque section logique utilise une balise <section> avec un attribut id pour permettre la navigation par ancres. Le pied de page se place dans un <footer>.
Cette structure n’a rien de décoratif. Un lecteur d’écran s’appuie sur ces balises pour naviguer entre les sections. Un recruteur qui ouvre le code source (et oui, pour un poste de développeur web, certains le font) repère immédiatement si le HTML est propre ou bricolé.
A lire en complément : Agrandir une photo sur Instagram : les outils indispensables
<header>pour l’en-tête : nom, rôle, navigation principale avec liens d’ancrage vers chaque section<section id="projets">pour chaque bloc thématique, avec un<h2>en premier enfant<article>à l’intérieur d’une section projets pour isoler chaque réalisation individuellement<footer>pour les coordonnées et liens externes (GitHub, LinkedIn)
Ce squelette sémantique fonctionne sans CSS. Si le portfolio reste lisible et logique sans aucune feuille de style, le balisage est correct.
Section projets pour portfolio développeur : documenter les contraintes, pas seulement le résultat
La section projets est le coeur du portfolio. La plupart des développeurs y placent un titre, une capture d’écran et un lien vers GitHub. Le problème : cette approche ne dit rien sur la compétence réelle.
Les recruteurs tech recherchent aujourd’hui la capacité à documenter comment un projet a été construit, pas seulement ce qu’il produit. Chaque projet gagnerait à suivre une sous-structure HTML précise :
- Un
<h3>avec le nom du projet - Un paragraphe de contexte : quel problème ce projet résout, pour qui, dans quel cadre
- La stack utilisée, présentée dans une liste
<ul>ou un petit tableau : langages, frameworks, outils de build - Les contraintes techniques rencontrées : dette technique héritée, compatibilité navigateur, performance cible
- Un paragraphe sur les compromis faits et, si pertinent, ce qui serait fait différemment aujourd’hui
Ce dernier point (les compromis et le recul) est un signal fort de maturité d’ingénierie. Écrire « j’ai utilisé React » ne distingue personne. Écrire « j’ai choisi React pour le state management complexe du formulaire multi-étapes, mais Next.js aurait simplifié le routage » montre une réflexion technique concrète.
Combien de projets afficher
Trois à cinq projets suffisent. Un portfolio avec douze projets dont huit sont des exercices de tutoriel dilue le signal. Trois projets documentés en profondeur valent mieux que dix captures d’écran.
Section compétences en HTML : structurer sans tomber dans la liste générique
La section compétences est la plus galvaudée des portfolios. Des barres de progression CSS indiquant « JavaScript : 85 % » ne transmettent aucune information exploitable.
Une approche plus efficace consiste à séparer les compétences techniques des compétences non techniques dans deux sous-sections distinctes. Pour la partie technique, un tableau HTML simple avec deux colonnes (catégorie et technologies) structure mieux l’information qu’une liste à puces interminable.
| Catégorie | Technologies |
|---|---|
| Frontend | HTML, CSS, JavaScript, React |
| Backend | Node.js, Express, PostgreSQL |
| Outils | Git, GitHub, VS Code, Figma |
Pour les compétences non techniques (communication, collaboration, gestion du temps, résolution de problèmes), un paragraphe court qui les relie à un contexte projet concret produit plus d’effet qu’une liste sèche. Par exemple : « Coordination avec un designer UX sur le projet X, livraison itérative en sprints de deux semaines. »
Section contact et liens GitHub : le code HTML qui convertit
Un formulaire de contact codé en HTML pur avec les balises <form>, <label>, <input> et <textarea> démontre une compétence frontend de base. Chaque champ associe un <label> à son <input> via l’attribut for. C’est un détail d’accessibilité que beaucoup de templates gratuits négligent.
Les liens vers GitHub, LinkedIn ou un profil sur une plateforme comme dev.to se placent dans le <footer>. Utilisez des balises <a> avec l’attribut rel="noopener noreferrer" et target="_blank" pour les liens externes. Ce n’est pas du CSS, c’est du HTML de base, et l’omettre signale un manque de rigueur.
L’attribut meta description dans le head
Même si le portfolio ne vise pas un référencement massif, une balise <meta name="description"> bien rédigée dans le <head> permet à Google d’afficher un extrait pertinent si quelqu’un cherche votre nom. Un portfolio sans meta description laisse Google choisir un extrait aléatoire de la page.
Accessibilité HTML du portfolio : attributs souvent oubliés
Un portfolio développeur qui néglige l’accessibilité envoie un mauvais signal, surtout pour un poste frontend. Trois attributs HTML font la différence sans nécessiter de JavaScript :
L’attribut alt sur chaque balise <img> décrit le contenu de l’image pour les lecteurs d’écran. L’attribut lang="fr" sur la balise <html> indique la langue du document. L’attribut aria-label sur les liens d’icônes (un logo GitHub sans texte visible, par exemple) fournit un libellé accessible.
Ces attributs ne demandent aucune ligne de CSS ni de JavaScript, et leur absence se repère en quelques secondes dans le code source. Pour un recruteur technique, un portfolio accessible démontre une attention au détail qui dépasse la simple capacité à produire du code fonctionnel.
Le portfolio HTML le plus convaincant reste celui où chaque ligne de balisage a une raison d’exister. Supprimer les <div> superflues, documenter ses projets avec leurs contraintes réelles et soigner les attributs d’accessibilité produit un résultat plus solide que n’importe quel template prêt à l’emploi.
