Réalisations

Conception d'un portfolio professionnel

Réalisation d'un portfolio complet avec Next.js, GSAP, i18n bilingue, conformité RGPD, analytics et blog technique.

Projet personnelNext.jsReactGSAPTypeScriptTailwind CSSMDX

Présentation

Un projet commencé le 12 mars 2026.
L'historique Git situe la création de cette version du portfolio au 12 mars 2026, avec une initialisation à partir de Next.js. Git enregistre les différentes versions du code et permet de retrouver la date ainsi que la nature des premières modifications. Cette version ne correspond pas à ma première présence professionnelle en ligne : elle constitue une reconstruction destinée à remplacer des supports antérieurs qui ne répondaient plus à mes objectifs de formation et de présentation.
Une réalisation d'abord imposée par ma formation.
La raison initiale du projet était académique. Le diplôme que je préparais exigeait un portfolio et son contenu faisait l'objet d'une évaluation selon une grille précise. Il ne suffisait donc pas de publier une page esthétique avec mon nom et quelques technologies. Le site devait présenter mon parcours, comparer mes compétences, développer chaque compétence, raconter plusieurs réalisations, relier les contenus entre eux et fournir des preuves. Cette contrainte explique l'ampleur prise progressivement par le projet.
Un ancien portfolio devenu insuffisant.
Avant cette reconstruction, je possédais déjà un portfolio et une page de présentation sur GitHub. Une page de profil GitHub permet d'afficher une introduction, des liens et des dépôts de code sur la plateforme utilisée pour héberger des projets. Ces supports donnaient un premier aperçu de mon activité, mais ils ne correspondaient pas aux attentes des examinateurs du diplôme. Ils manquaient notamment du niveau de rédaction, de structuration et de mise en relation demandé entre compétences, expériences et réalisations.
Deux publics principaux : les examinateurs et les recruteurs.
Le premier public est constitué des examinateurs qui doivent vérifier que le portfolio répond aux critères du diplôme. Le second regroupe les recruteurs qui souhaitent comprendre mon profil professionnel sans parcourir tout mon historique de code. Ces deux publics n'ont pas exactement la même lecture : les examinateurs recherchent la présence et la profondeur des rubriques imposées, tandis que les recruteurs doivent pouvoir identifier rapidement mon domaine, mon niveau, mes réalisations et ma manière de travailler.
Une vitrine professionnelle sans recherche d'emploi immédiate.
Je suis déjà en poste et le portfolio n'a donc pas pour objectif direct de me faire obtenir un emploi à court terme. Il doit plutôt rendre mes capacités professionnelles accessibles et compréhensibles. Un visiteur n'est pas obligé d'accomplir une action commerciale particulière après sa lecture. Le résultat attendu est d'abord une meilleure connaissance de ce que je sais faire, des problèmes que j'ai résolus et du type de responsabilités que je peux prendre.
Présenter des capacités plutôt qu'une simple liste de technologies.
L'image recherchée est celle d'un développeur capable de comprendre un besoin métier, de concevoir une solution et de la maintenir dans la durée. Une technologie seule ne démontre pas cette capacité : écrire « Odoo », « Next.js » ou « PostgreSQL » ne dit pas comment ces outils ont été utilisés. Le portfolio associe donc les compétences à des situations, des résultats, des limites et des axes d'évolution. Il cherche à montrer une pratique professionnelle plutôt qu'un inventaire de mots-clés.
Faire apparaître mon objectif de devenir développeur confirmé et référence Odoo.
Ce positionnement est présenté à travers mes compétences, mes projets en cours et mes réalisations. Les articles consacrés à la migration d'Odoo, aux modules métier et aux intégrations montrent que je ne me limite pas à configurer un ERP. Ils expliquent comment j'analyse son code, adapte ses fonctions, automatise des processus, traite les retours des utilisateurs et prends en charge des changements structurants. L'ensemble doit rendre visible une progression vers un rôle de développeur confirmé et de référent capable d'accompagner les décisions autour d'Odoo.
Montrer un profil plus large grâce aux projets en cours.
Mon projet professionnel ne se limite pas à Odoo. Je souhaite développer une expertise plus large dans l'intégration d'ERP avec des systèmes externes au moyen d'API personnalisées pour des clients finaux. Une API, ou interface de programmation, permet à deux logiciels d'échanger des données et de déclencher des opérations selon des règles définies. Les projets présentés autour de la Business Intelligence, du site B2B et des synchronisations montrent cette ouverture au-delà du cœur de l'ERP.
Une construction sur mesure pour répondre à la grille.
Le projet ne part pas d'un thème de portfolio prêt à remplir. Je l'ai développé afin de contrôler la structure, la navigation, les relations entre les compétences et les réalisations ainsi que la présentation bilingue. Ce choix sur mesure n'implique pas de réinventer chaque composant visuel : il signifie que l'architecture et les contenus sont adaptés au besoin d'évaluation. Les bibliothèques et composants existants restent utilisés lorsqu'ils apportent une base maintenable et accessible.
Une première version beaucoup plus légère.
Le périmètre initial présentait principalement mes compétences et mon parcours de manière synthétique. Cette première version ressemblait davantage à un portfolio professionnel classique : une introduction, quelques domaines techniques et une chronologie. Elle ne développait pas encore chaque compétence dans un article complet et ne racontait pas les réalisations selon les objectifs, risques, étapes, acteurs, résultats, lendemains et regard critique demandés par la grille.
Un projet élargi par les exigences du diplôme.
Les pages, sections et volumes de rédaction actuels n'étaient pas tous prévus au démarrage. Leur ajout répond à l'obligation de détailler les compétences et les réalisations plutôt qu'à une volonté de multiplier artificiellement les écrans. Le projet a progressivement intégré une cartographie comparative des compétences, des articles approfondis, une navigation circulaire entre preuves et savoir-faire, une frise de parcours et des contenus plus explicites pour un lecteur extérieur au domaine.
Un site destiné à rester vivant après l'évaluation.
Même si la formation a déclenché cette reconstruction, le portfolio ne doit pas devenir une archive figée une fois le diplôme obtenu. Il continuera à présenter mes nouvelles responsabilités, mes projets et mes apprentissages. Le blog constitue le principal moyen de le faire évoluer régulièrement. Cette continuité transforme une obligation académique ponctuelle en support professionnel utilisable pendant plusieurs années.
Next.js et React choisis pour les performances et l'habitude.
J'ai retenu Next.js et React parce que je connaissais déjà cet écosystème et qu'il fournit un cadre adapté à un site mêlant pages statiques, contenus, composants interactifs et logique serveur. Next.js organise notamment le routage, le rendu, les métadonnées et l'optimisation de ressources autour de React. La performance dépend toujours de l'implémentation finale, mais ce socle permet de limiter le JavaScript aux composants qui en ont besoin et de produire des pages structurées pour le référencement.
Des outils choisis pour écrire un code propre sans réinventer les bases.
TypeScript vérifie les types et réduit certaines incohérences avant l'exécution. Tailwind CSS fournit des classes de style composables. shadcn/ui apporte des composants accessibles dont le code reste modifiable dans le projet. GSAP prend en charge les animations qui demandent un contrôle plus précis. Le clean code, ou code propre, désigne un code lisible, structuré et suffisamment simple à modifier. Employer ces outils ne garantit pas automatiquement cette qualité, mais évite de reconstruire des mécanismes courants et permet de concentrer le travail sur les besoins propres au portfolio.
Un design personnel nourri par d'autres portfolios.
Je suis responsable de la direction visuelle du site, mais je ne prétends pas avoir créé chaque idée sans référence. Je me suis inspiré de portfolios déjà consultés pour observer leur hiérarchie, leur navigation, leur manière de présenter des projets et leur usage des animations. L'objectif n'était pas de reproduire un site précis, mais d'identifier les conventions efficaces puis de les adapter à mon contenu, à ma palette et à l'image professionnelle recherchée.
Plusieurs journées de travail réparties dans une évolution continue.
Le portfolio représente plusieurs jours complets de travail, auxquels s'ajoutent les périodes de rédaction, de correction et d'amélioration réalisées au fil des retours. Je ne dispose pas d'un relevé d'heures assez précis pour annoncer un total fiable. Cette durée reste ouverte, puisque chaque nouvelle expérience, preuve ou exigence peut entraîner une modification. Le projet doit donc être évalué comme un produit maintenu dans le temps et non comme une page terminée en une seule session.
Une utilisation transparente de Codex comme outil d'assistance.
J'ai utilisé Codex pendant la réalisation, notamment pour m'aider à structurer, reformuler et enrichir les contenus rédactionnels. Un outil d'assistance peut accélérer l'exploration d'une base de code ou proposer une première formulation, mais il ne connaît pas automatiquement la réalité de mon expérience. Je reste responsable de relire les textes, corriger les erreurs, fournir les faits et décider de ce qui est publié. Cette transparence est importante : le portfolio doit représenter mon parcours, même lorsque des outils modernes participent à sa production.
Une version française et anglaise pour élargir la lecture.
Le français est la langue principale du site, tandis que l'anglais augmente sa portée auprès de recruteurs ou interlocuteurs qui ne lisent pas le français. Les éléments d'interface, les métadonnées et les principales pages existent donc dans les deux langues. Le bilinguisme ne doit pas produire deux portfolios contradictoires : les informations essentielles doivent rester cohérentes et être mises à jour ensemble.
Des articles MDX conservés dans leur langue de rédaction.
Les articles techniques avaient été écrits en français avant la mise en place complète du bilinguisme. Leur contenu reste donc principalement dans cette langue, même lorsque leur titre et leur description sont traduits dans l'interface. MDX est un format qui combine le texte structuré de Markdown avec la possibilité d'insérer des composants. Une traduction intégrale de tous les articles demanderait une maintenance éditoriale importante ; le site indique cette limite et laisse le navigateur fournir une traduction lorsque le lecteur en a besoin.
Un blog destiné à partager des solutions difficiles à trouver.
Le blog ne sert pas uniquement à améliorer le référencement ou à remplir une rubrique. Il me permet de documenter des solutions à des problèmes pour lesquels je n'avais pas trouvé de réponse en ligne, ou pas sous une forme suffisamment claire. Chaque article doit pouvoir faire gagner du temps à un autre développeur confronté au même contexte. Cette démarche transforme une difficulté rencontrée pendant un projet en connaissance réutilisable et démontre également ma capacité à expliquer une solution technique.
Un domaine public et une identité stable.
Le portfolio est publié sur le domaine personnalisé orhanmadiassani.com. Un domaine personnalisé fournit une adresse indépendante de l'URL technique de l'hébergeur et peut être conservé même si l'infrastructure change. Il centralise ma présence professionnelle et permet de partager une adresse stable dans un CV, un profil GitHub ou un échange avec un recruteur.
Des preuves limitées par la confidentialité de l'entreprise.
Une partie importante de mes réalisations concerne Odoo et les outils internes de mon employeur. Je ne peux pas publier librement les données, chiffres, informations clients ou extraits de code qui révéleraient son fonctionnement. Les preuves doivent donc être anonymisées, censurées ou remplacées par des captures autorisées. Cette limite ne signifie pas que la réalisation n'existe pas : elle impose de démontrer ma démarche et ma valeur ajoutée sans exposer des informations appartenant à l'entreprise.
Un premier critère de réussite centré sur la clarté du profil.
Pour la première mise en ligne, le résultat minimal attendu était un site qui me présente correctement ainsi que mes compétences. Il devait permettre à une personne qui ne me connaît pas de comprendre mon domaine, mon parcours et mes principaux savoir-faire. Les fonctions plus avancées — blog, recherche, analytics, animations ou navigation détaillée — pouvaient enrichir cette base, mais elles ne remplaçaient pas ce critère fondamental : donner une représentation professionnelle fidèle et compréhensible de mon profil.

Retour au sommaire

Objectifs, contexte et enjeux

Viser la totalité des 100 points de la grille.
L'objectif n'est pas seulement d'obtenir une note suffisante pour valider le portfolio. Je cherche à répondre à l'ensemble des critères et à atteindre 100 % du barème. Cette ambition impose de traiter aussi bien les éléments visibles sur toutes les pages — identité, photo et navigation — que les articles détaillés, les preuves, les liens circulaires, le parcours, le contact et l'orthographe. La qualité graphique ne peut pas compenser une rubrique absente lorsque la grille attribue les points à des éléments explicitement vérifiables.
Préparer une version complète pour août 2026.
La période visée pour terminer le travail d'évaluation est août 2026, même si la date exacte n'est pas encore confirmée. Cette incertitude impose de conserver une marge et de traiter d'abord ce qui conditionne directement la note. Une échéance approximative ne doit pas devenir une raison pour repousser les vérifications : le contenu principal doit être prêt avant que la date officielle ne transforme chaque correction en urgence.
Ne laisser aucun critère demandé sans réponse.
La priorité absolue consiste à présenter tous les points imposés. Chaque compétence doit contenir sa définition, ses preuves, son autocritique et son évolution ; chaque réalisation doit couvrir sa présentation, ses objectifs, ses risques, ses étapes, ses acteurs, ses résultats, ses lendemains et son regard critique. Cette exhaustivité est plus importante pour l'évaluation qu'une nouvelle animation ou une fonction qui n'apparaît pas dans le barème.
Garantir quatre contenus essentiels dès la version évaluée.
Le noyau obligatoire comprend une présentation de mon profil, mes compétences humaines, mes compétences techniques et mes réalisations. Ces rubriques permettent de comprendre qui je suis, comment je travaille, ce que je sais mettre en œuvre et dans quelles situations je l'ai démontré. Le parcours et les preuves complètent cette lecture, mais aucun enrichissement technique ne peut remplacer ces quatre piliers éditoriaux.
Distinguer le périmètre d'évaluation des enrichissements personnels.
La traduction anglaise et le blog apportent une valeur professionnelle, mais pourraient être reportés sans rendre le portfolio non conforme à la grille française. Le bilinguisme élargit le lectorat et le blog démontre ma capacité à transmettre des solutions ; ils ne doivent toutefois pas retarder un article de compétence obligatoire ou une réalisation incomplète. Cette distinction permet de prioriser sans abandonner les fonctions qui feront vivre le site après l'examen.
Rendre chaque critère facilement vérifiable par les examinateurs.
Le portfolio doit éviter de forcer l'évaluateur à deviner où se trouve une information. Le menu principal, les sous-menus, les titres de section et les liens entre compétences et réalisations doivent lui permettre de retrouver rapidement chaque élément. L'objectif n'est pas uniquement de posséder le contenu dans le code : il doit être visible, compréhensible et accessible selon le parcours attendu par la grille.
Prévoir une correspondance plus explicite avec la grille.
Le site ne dispose pas encore d'une page publique reliant directement chaque critère à son emplacement. La structure actuelle et la checklist interne permettent déjà de suivre la conformité, mais une vue de correspondance pourrait faciliter la dernière vérification avant l'évaluation. Elle ne devrait pas transformer le portfolio en copie brute du barème ; elle servirait plutôt d'index de contrôle permettant de prouver qu'aucune exigence n'a été oubliée.
Développer les contenus sans rester superficiel.
Je souhaite fournir suffisamment de détails pour que les examinateurs puissent comprendre le contexte, les décisions et ma valeur ajoutée, même lorsqu'ils ne connaissent pas Odoo ou les technologies citées. Chaque notion spécialisée doit être définie et chaque affirmation importante illustrée. La quantité n'est cependant pas un objectif isolé : un paragraphe doit expliquer une information, une relation de cause à effet, un résultat ou un recul utile.
Conserver une lecture structurée malgré la profondeur.
Les articles doivent être divisés en paragraphes, sous-titres et expressions mises en valeur afin qu'un lecteur puisse d'abord les parcourir, puis approfondir les points qui l'intéressent. Les détails superflus, les répétitions et les informations sans lien avec la compétence ou la réalisation doivent être retirés. Cette structure concilie deux besoins opposés : fournir beaucoup de matière pour l'évaluation et ne pas transformer chaque page en bloc de texte impossible à consulter.
Atteindre au moins 95 dans chaque catégorie Lighthouse.
L'objectif technique est d'obtenir un score minimal de 95 sur 100 pour les catégories mesurées par Lighthouse, notamment la performance, l'accessibilité, les bonnes pratiques et le référencement technique. Lighthouse exécute des contrôles automatisés sur une page et signale certains problèmes de chargement, de contraste, de structure ou de configuration. Le score n'est pas une preuve absolue de qualité, mais il fournit un seuil reproductible pour repérer une régression importante.
Appliquer le même seuil à l'accessibilité.
L'accessibilité doit elle aussi rester au-dessus de 95 dans les audits. Cela implique notamment une structure de titres cohérente, une navigation utilisable, des libellés compréhensibles, des contrastes suffisants et des animations qui ne bloquent pas le contenu. Un score automatisé ne remplace pas les vérifications humaines au clavier ou avec différents réglages, mais l'objectif chiffré empêche de considérer l'accessibilité comme une amélioration facultative de fin de projet.
Ne pas poursuivre artificiellement un classement SEO.
Je mets en place les fondations nécessaires au référencement — métadonnées, sitemap, contenu structuré, performance et domaine personnalisé — mais je ne fixe pas d'objectif de position précis dans un moteur de recherche. Si le portfolio ressort sur des recherches pertinentes, ce sera un bénéfice. La priorité reste de répondre à l'évaluation et de fournir une adresse professionnelle claire, plutôt que d'écrire les articles uniquement pour attirer du trafic.
Ajouter un formulaire de contact pour mon usage professionnel.
L'espace de contact n'était pas seulement une exigence potentielle du portfolio : je voulais offrir un moyen direct de me joindre depuis le site. Le formulaire doit valider les informations, envoyer le message à une adresse surveillée et indiquer clairement son résultat au visiteur. Il complète les coordonnées publiques sans obliger la personne à ouvrir un autre service ou à recopier manuellement une adresse.
Comprendre l'utilisation du site grâce aux analytics.
Les statistiques doivent m'aider à savoir quelles pages sont consultées et comment les visiteurs parcourent le portfolio. Les analytics regroupent des mesures d'audience comme les pages vues, les entrées et certaines interactions. L'objectif n'est pas de collecter le maximum d'informations personnelles, mais d'identifier les contenus utiles, ceux qui restent peu visibles et les parcours qui pourraient être améliorés. Leur chargement doit rester conditionné au consentement lorsque la réglementation l'exige.
Proposer volontairement une version anglaise.
Le bilinguisme n'était pas imposé par la formation. Je l'ai ajouté pour accroître la portée du portfolio auprès de recruteurs ou professionnels anglophones. Cette fonction doit rester secondaire par rapport à la complétude française, mais elle montre aussi que l'architecture peut gérer plusieurs langues et que les informations principales de mon profil sont accessibles au-delà d'un contexte exclusivement francophone.
Publier des preuves professionnelles contrôlées.
Pour les réalisations Odoo, je prépare moi-même les captures et extraits en censurant les données, chiffres et identifiants confidentiels. Je montre ensuite ce que je souhaite publier aux personnes concernées par le projet afin d'obtenir leur validation. Ce processus doit permettre de fournir des preuves concrètes sans exposer les clients, les processus internes ou le code appartenant à l'entreprise. L'objectif est de démontrer mon travail avec l'autorisation des parties qui en supportent le risque.
Utiliser Codex comme accélérateur de première passe.
Codex m'aide à produire plus rapidement une première rédaction structurée à partir de mes réponses. Il ne doit pas décider à ma place de ce qui s'est passé ni remplacer mon jugement. Je relis donc manuellement chaque texte, puis je modifie les formulations qui ne correspondent pas exactement à mon expérience. L'objectif est de gagner du temps sur la mise en forme tout en conservant une responsabilité humaine complète sur le sens publié.
Maintenir un portfolio vivant et actualisé.
Les compétences, projets, objectifs et résultats peuvent devenir obsolètes. Je prévois donc de relire régulièrement le site et de mettre à jour les contenus lorsqu'une situation évolue. Cette maintenance n'est pas encore associée à un calendrier automatisé : elle repose sur des relectures et sur l'ajout de nouvelles expériences. Le blog et la structure modulaire doivent faciliter ces évolutions sans nécessiter une reconstruction complète du site.

Retour au sommaire

Risques et mesures de maîtrise

Un échec principalement causé par un contenu absent ou insuffisant.
Le risque majeur de l'évaluation n'est pas une panne technique spectaculaire, mais le manque de contenu ou le non-respect d'un élément demandé. Une compétence peut être réelle et pourtant ne rapporter aucun point si sa définition, sa preuve ou son évolution n'apparaît pas. La réduction de ce risque repose sur une lecture critère par critère, une checklist mise à jour et une vérification finale du site rendu, pas seulement des données présentes dans les fichiers.
Une couverture difficile à contrôler sans correspondance publique.
Le portfolio doit permettre aux examinateurs de retrouver les critères, mais il ne possède pas encore de page les reliant explicitement à leurs emplacements. Une navigation claire réduit le problème sans garantir qu'une exigence discrète ne soit oubliée. La checklist interne joue actuellement ce rôle de contrôle. Avant l'évaluation, elle devra être comparée à la version réellement accessible en ligne et, si nécessaire, complétée par un index visible ou un document de vérification.
Un contenu trop superficiel malgré un grand nombre de pages.
Multiplier les rubriques peut donner une impression de complétude sans démontrer la maîtrise. Une anecdote sans contexte, une compétence sans résultat ou un terme technique non défini resterait insuffisant. Le risque est particulièrement fort pour les sujets que je connais bien, car je peux supposer à tort que le lecteur comprend Odoo, un ORM, une API ou une migration. Chaque article doit donc répondre aux questions « pourquoi », « comment », « avec quel résultat » et « avec quel recul ».
L'excès inverse : écrire sans apporter d'information.
Chercher à éviter une présentation superficielle peut produire des textes trop longs, répétitifs ou remplis de définitions inutiles. La profondeur ne se mesure pas au nombre de paragraphes. Chaque sous-titre doit apporter un angle distinct, les détails doivent soutenir la compréhension et les répétitions doivent être supprimées. La structure permet au lecteur de parcourir une page, mais elle ne compense pas un contenu qui reformule plusieurs fois la même idée.
Des preuves Odoo censurées pouvant devenir trop vagues.
Le risque principal lié aux projets de l'entreprise est de ne pas suffisamment expliquer ma contribution après avoir retiré les informations confidentielles. Une capture entièrement masquée ou un résultat sans ordre de grandeur peut ne plus prouver grand-chose. Je dois trouver un équilibre : anonymiser les clients, chiffres et données internes tout en conservant le problème, les décisions, les responsabilités et les effets observables. La validation par les parties concernées confirme ensuite que cet équilibre ne crée pas d'exposition indésirable.
La publication accidentelle d'une information confidentielle.
Je prépare moi-même les preuves et peux donc commettre une erreur de censure ou oublier qu'un nom apparaît dans un arrière-plan, une URL, un journal ou une métadonnée. Montrer les éléments aux personnes concernées avant publication ajoute un second contrôle. Les extraits doivent aussi être vérifiés dans leur forme finale sur le site, car un fichier correctement censuré peut être accompagné d'une légende ou d'un texte révélant indirectement ce que l'image masque.
Une première passe Codex pouvant déformer l'expérience.
L'assistance rédactionnelle peut mal retranscrire une réponse orale, remplacer un terme par une notion différente ou supprimer une nuance considérée à tort comme secondaire. Elle peut aussi produire une explication convaincante mais non conforme aux faits. Le texte généré ne constitue donc jamais une source. Mes réponses, les fichiers du projet, les preuves autorisées et ma relecture manuelle restent les références qui déterminent la version publiée.
Une authenticité dépendante de la relecture humaine.
Je relis et édite manuellement l'intégralité des contenus produits avec assistance afin de vérifier qu'ils expriment bien ce que je veux dire. Cette étape doit contrôler les faits, mais aussi le niveau de responsabilité attribué : un texte ne doit pas transformer une contribution d'équipe en réalisation individuelle ni présenter une intention comme un résultat. Le volume croissant du portfolio rend cette relecture exigeante ; elle doit être effectuée section par section plutôt qu'en une seule session à la veille de l'évaluation.
Des informations professionnelles susceptibles de devenir obsolètes.
Mon niveau, les versions d'Odoo, l'état d'un projet, les formations prévues ou les fonctions du site peuvent évoluer. Un contenu exact en 2026 peut devenir trompeur plusieurs mois plus tard. Je prévois de repérer ces écarts en relisant le portfolio et en le mettant à jour avec mes nouvelles expériences. L'absence de calendrier fixe crée néanmoins un risque d'oubli ; les dates et formulations comme « actuellement » doivent être surveillées en priorité.
Des animations pouvant nuire au message.
GSAP et les transitions rendent le site plus vivant, mais un effet ajouté sans fonction peut ralentir la page, distraire le lecteur ou rendre un contenu difficile à utiliser. Les animations doivent donc rester simples, courtes et limitées aux éléments qui bénéficient réellement d'une mise en scène. Elles ne doivent jamais masquer une information obligatoire ni empêcher un utilisateur ayant demandé moins de mouvement d'accéder au contenu.
Des traductions française et anglaise pouvant diverger.
Lorsque la version française évolue, sa traduction peut conserver une ancienne responsabilité, un chiffre ou un objectif. Le visiteur reçoit alors deux profils différents selon la langue. Chaque ajout de contenu localisé doit donc modifier les deux versions et les tests doivent vérifier la présence des titres essentiels. Les articles MDX uniquement en français doivent être clairement signalés afin que cette décision éditoriale ne soit pas confondue avec une traduction cassée.
Des scores Lighthouse sensibles aux conditions.
Le seuil de 95 fournit une cible, mais le résultat varie selon la page, l'appareil simulé, le réseau, le contenu chargé et les services externes. Un audit local avec le cache chaud peut masquer une expérience plus lente sur téléphone. Les mesures doivent donc être répétées sur les pages principales, en préproduction et après les changements importants. Une note élevée ne dispense pas de vérifier la lecture, la navigation au clavier et la perception sur un appareil réel.
Des messages de contact pouvant ne jamais être délivrés.
Le formulaire dépend d'une validation correcte, de l'action serveur, de Resend et d'une adresse destinataire disponible. Un échec dans l'une de ces étapes peut afficher un site fonctionnel tout en perdant une demande professionnelle. L'interface doit signaler l'erreur sans prétendre que le message a été remis. Les journaux et les tests doivent fournir assez d'informations pour diagnostiquer une non-livraison sans exposer le contenu privé du message.
Le spam pouvant épuiser les quotas d'envoi ou dégrader le service.
Des soumissions automatisées peuvent consommer rapidement le quota Resend, remplir la boîte de réception et solliciter inutilement le serveur. Dans un cas important, elles peuvent rendre l'envoi indisponible pour de vrais visiteurs. Le projet utilise plusieurs protections — champ piège, délai minimal, limitation de fréquence et reCAPTCHA lorsque configuré — mais aucune couche ne suffit seule. Leur comportement doit rester vérifié et les limites adaptées aux conditions réelles d'hébergement.
Un risque de non-conformité au RGPD avec les analytics.
Le Règlement général sur la protection des données, ou RGPD, encadre le traitement des données personnelles. Charger un outil de mesure avant le consentement, conserver un choix de manière ambiguë ou ne pas permettre un refus effectif créerait un risque juridique et éthique. Les scripts analytics doivent donc rester désactivés tant que la catégorie correspondante n'a pas été acceptée, tandis que les fonctions nécessaires comme la langue ou le thème peuvent fonctionner indépendamment.
Un périmètre enrichi mais encore gérable.
L'ajout du blog, du bilinguisme, des animations, des analytics et des nombreux articles a probablement augmenté la durée du projet. Il n'a pas encore rendu le scope, ou périmètre, ingérable, car le site reste une application JavaScript relativement ciblée. Le risque serait de continuer à ajouter des fonctions facultatives avant d'avoir terminé les critères notés. La règle de priorité doit rester simple : conformité et contenu d'abord, enrichissements ensuite.
Une dette de structure identifiée puis traitée.
Le fichier central des réalisations avait fini par dépasser 790 Ko et réunissait les cinq études de cas dans les deux langues. Même si le comportement restait correct, cette concentration ralentissait la manipulation, compliquait la relecture et augmentait le risque de conflit lorsqu'un seul article changeait. J'ai depuis placé chaque réalisation dans son propre module, déplacé les types partagés dans un fichier dédié et conservé un index public léger. Le risque n'est donc plus le poids d'un fichier unique, mais la nécessité de maintenir les mêmes contrats de données entre plusieurs modules.
Une dépendance remplaçable envers les services externes.
Le site utilise notamment Vercel pour l'hébergement, Resend pour les courriels et des services de mesure lorsque le consentement le permet. Si l'un d'eux fermait ou devenait indisponible durablement, je pourrais déplacer l'application ou remplacer le service concerné. Le projet reste une application JavaScript dont le code et le contenu sont versionnés. Cette portabilité réduit le risque de disparition, mais une migration demanderait tout de même de reconfigurer le domaine, les variables d'environnement et les fonctions dépendantes.
Une date d'août encore incertaine.
L'absence de jour d'évaluation confirmé complique la planification de la dernière phase. Attendre la date exacte ferait courir le risque de découvrir trop tard une rubrique manquante ou une preuve non validée. Je dois donc travailler comme si la première échéance possible était la bonne, terminer les contenus obligatoires, puis utiliser le temps restant pour les audits, la relecture et les fonctions secondaires.
Un objectif de 100 % exigeant une vérification du rendu réel.
Une checklist peut être marquée comme conforme alors qu'un lien est cassé, un menu ne fonctionne pas sur mobile ou un texte n'apparaît pas dans la bonne langue. La dernière validation devra donc parcourir le site comme un examinateur, depuis la page d'accueil jusqu'aux preuves et aux liens circulaires. Le principal risque de perte de points sera maîtrisé seulement lorsque les critères seront présents dans la version effectivement publiée, pas uniquement déclarés comme terminés dans le dépôt.

Retour au sommaire

Les étapes — ce que j'ai fait

Cadrer le contenu avant de multiplier les pages.
J'ai d'abord dressé la liste des éléments que le portfolio devait contenir : présentation, compétences humaines et techniques, réalisations, parcours, preuves et contact. La grille d'évaluation a ensuite été transformée en liste de suivi dans un fichier Markdown du dépôt. Markdown est un format texte léger qui permet ici de conserver une liste à cocher au même endroit que le code. Cette méthode me donne une référence vérifiable pour suivre ce qui est terminé, partiel ou absent sans dépendre de ma mémoire.
Installer le bilinguisme avant de construire les pages.
La première fonction structurante développée a été la traduction française et anglaise. J'avais compris dès le départ que des recruteurs internationaux pouvaient consulter le site ; j'ai donc évité d'ajouter la langue après coup. Toutes les pages applicatives se trouvent sous un segment d'URL [locale], une locale étant le code qui désigne la langue et les conventions régionales utilisées, par exemple fr ou en. Comme cette structure précédait la page d'accueil, les compétences et les réalisations, aucune migration tardive de routes déjà publiées n'a été nécessaire.
Détecter la langue dès l'arrivée sur le site.
Un proxy Next.js intercepte les requêtes qui ne contiennent pas encore de langue et les redirige vers l'adresse appropriée. Un proxy est une couche exécutée avant l'affichage d'une page. Il cherche d'abord le cookie NEXT_LOCALE, qui mémorise un choix antérieur, puis l'en-tête Accept-Language envoyé par le navigateur, et utilise le français par défaut si aucune préférence exploitable n'existe. Le sélecteur de langue remplace ensuite le premier segment de l'URL, conserve le reste du chemin et enregistre la préférence pendant un an.
Séparer le chargement serveur et l'usage interactif des traductions.
Les textes d'interface sont centralisés dans deux dictionnaires JSON, un par langue. JSON est un format structuré composé de clés et de valeurs. Les composants exécutés sur le serveur chargent uniquement le dictionnaire demandé, tandis qu'un contexte React limité transmet aux composants interactifs les libellés dont ils ont besoin. Ce choix évite de recopier des textes dans chaque composant et impose de mettre à jour les deux dictionnaires lorsqu'une nouvelle clé est créée. Le layout localisé génère aussi l'attribut lang directement sur le serveur, avant l'hydratation, pour les lecteurs d'écran et les moteurs de recherche.
Poser une architecture Next.js typée et réutilisable.
Le projet utilise l'App Router de Next.js, c'est-à-dire un système où l'arborescence des dossiers définit les routes et leurs mises en page. TypeScript fonctionne en mode strict afin de détecter davantage d'incohérences avant l'exécution. J'ai privilégié les Server Components, rendus côté serveur sans JavaScript interactif inutile dans le navigateur, puis réservé les Client Components aux formulaires, menus, animations, changements de thème et autres comportements nécessitant un état ou une action utilisateur.
Explorer l'identité visuelle dans Figma.
Avant de stabiliser l'interface, j'ai réalisé plusieurs essais dans Figma, un outil de conception d'interfaces, pour comparer les couleurs, les typographies, les espacements et l'organisation des blocs. J'ai retenu Roboto Flex pour le texte courant et Geist Mono pour les libellés techniques parce que cette combinaison correspondait au rendu professionnel et contemporain que je recherchais. Ces choix sont chargés par Next.js afin d'optimiser les fichiers de police et de limiter les décalages visuels au chargement.
Construire un système visuel commun à partir d'une bibliothèque de composants.
Plutôt que de redévelopper chaque bouton, champ ou carte de manière isolée, je me suis appuyé sur shadcn/ui et Base UI. Une bibliothèque de composants fournit des briques d'interface accessibles et personnalisables ; elle n'impose pas pour autant le design final. Les couleurs sont définies par des variables CSS au format OKLCH, un espace colorimétrique facilitant des variations cohérentes entre thème clair et sombre. Les composants réutilisables — boutons, cartes, badges, champs, titres de section et blocs d'apparition — garantissent ainsi les mêmes comportements sur l'ensemble du site.
Développer les contenus principaux dans un ordre progressif.
Après les fondations, j'ai construit la page d'accueil, puis les pages de compétences et enfin les pages de réalisations. La page d'accueil rassemble une accroche, une présentation synthétique, le parcours, les compétences, les projets, les preuves et un appel au contact. Les pages communes servent de premier niveau de lecture, tandis que chaque compétence ou réalisation possède une route détaillée. Cette progression m'a permis de valider d'abord la structure globale avant d'injecter les articles les plus volumineux.
Rendre l'identité et la navigation persistantes.
Le bandeau supérieur est positionné de façon fixe afin de rester disponible pendant le défilement. Il affiche ma photo, mon prénom et mon nom sur toutes les pages, ainsi que des intitulés courts pour les principales rubriques. Les sous-menus de compétences et de réalisations sont générés depuis les mêmes données que les pages, ce qui évite qu'un nouvel article existe sans être accessible. Sur mobile, ces listes deviennent des accordéons afin de rester manipulables sur un écran étroit ; le changement de langue et le thème clair ou sombre restent disponibles dans les deux versions du menu.
Modéliser dix compétences comparables.
J'ai défini dix fiches divisées en compétences humaines et techniques. Chacune contient un niveau chiffré commun sur 100, un type, une définition, des anecdotes, une autocritique, une évolution et les réalisations associées. La page commune transforme les dix valeurs en graphique radar : chaque axe correspond à une compétence et la distance au centre représente son niveau relatif. Cette représentation ne prétend pas être une mesure scientifique ; elle permet surtout de comprendre immédiatement la place de chaque compétence par rapport aux autres.
Donner à chaque compétence une structure éditoriale identique.
Une fiche détaille la définition professionnelle, les preuves et leurs résultats, mon niveau actuel, l'importance de la compétence, mes conseils et mon objectif d'évolution. Une barre reprend la même valeur que le radar pour conserver une lecture cohérente. Les anecdotes peuvent pointer vers une réalisation précise et la fin de la fiche liste toutes les réalisations liées. Un lecteur peut donc passer de l'affirmation d'une capacité à la situation concrète qui la démontre.
Structurer les cinq réalisations comme des études de cas.
Chaque réalisation est stockée avec un nom indépendant du contexte scolaire ou de l'entreprise, un résumé, un contexte, des technologies et des rubriques obligatoires : présentation, objectifs, risques, étapes, acteurs, résultats, suites et regard critique. La page de détail transforme ces données en sections numérotées et interprète les doubles astérisques comme du texte en gras. Ce mécanisme me permet de mettre en évidence les enjeux, décisions et résultats sans écrire un composant différent pour chaque projet.
Garantir la navigation circulaire par les données et les tests.
Chaque réalisation contient la liste de ses compétences et chaque compétence la liste de ses réalisations. Un test automatique parcourt les deux sens : si une compétence cite une réalisation, celle-ci doit citer la compétence en retour, et inversement. La navigation circulaire ne repose donc pas uniquement sur une vérification visuelle. Les pages génèrent ensuite les liens localisés à partir de ces relations, ce qui permet de suivre les preuves dans les deux directions.
Transformer le parcours en frise anti-chronologique.
La section consacrée aux expériences présente d'abord les périodes les plus récentes. Chaque entrée fournit un premier niveau de lecture — période, poste ou diplôme, organisation et logo — puis les responsabilités, la description et les liens associés. Les logos d'établissements et d'entreprises peuvent pointer vers leur site. Sur grand écran, une ligne verticale et des repères matérialisent la chronologie ; sur mobile, le contenu conserve son ordre sans dépendre de cet effet visuel.
Ajouter des animations discrètes dès la première version.
Les premières animations concernaient l'apparition des éléments de la page principale. Je voulais apporter du rythme sans détourner l'attention du contenu. GSAP, une bibliothèque JavaScript d'animation, est importé depuis un module central qui enregistre aussi ScrollTrigger, l'extension déclenchant un effet selon la position de défilement. Les animations sont limitées au composant concerné grâce au hook useGSAP et utilisent autoAlpha, qui combine visibilité et transparence pour éviter un flash de contenu avant le démarrage.
Unifier le défilement et les transitions entre pages.
Lenis, une bibliothèque de défilement fluide, et les transitions de pages ont été prévus dès le début. Lenis est synchronisé avec la boucle d'animation de GSAP afin que les effets liés au scroll restent alignés avec la position réellement affichée. À chaque changement de route, le nouveau contenu apparaît avec un léger déplacement vertical et un fondu. Le code détecte toutefois la préférence système prefers-reduced-motion et supprime ces mouvements pour les personnes qui demandent une interface moins animée.
Préserver le responsive et les préférences d'affichage.
Responsive signifie que la mise en page s'adapte à la largeur et au type d'écran. J'ai utilisé les points de rupture de Tailwind CSS pour réorganiser grilles, menus, tailles de texte et espacements sur téléphone, tablette et ordinateur. Le thème est géré avec next-themes et applique une classe claire ou sombre sans dupliquer les composants. Le formulaire, le responsive, le changement de thème et le changement de langue font partie des parcours que je considère prioritaires lors des tests.
Créer un blog technique avec MDX.
Les six articles sont écrits en MDX, un format qui associe la syntaxe simple de Markdown à la possibilité d'insérer des composants React. Le contenu long reste en français, tandis que le titre, la description, la date et les tags sont traduits dans les dictionnaires ; la version anglaise signale explicitement cette limite. Cette organisation me permet de publier des solutions techniques difficiles à trouver tout en conservant une mise en page homogène avec le reste du portfolio.
Indexer le contenu réel des articles.
La page du blog ne recherche pas seulement dans les titres. Au moment de construire l'index, le code lit chaque fichier MDX, retire les balises et éléments de mise en forme, puis combine son texte avec le titre, la description et les tags. La recherche ignore la casse et les accents, et les filtres par thème ainsi que la requête sont reflétés dans l'URL. Une adresse partagée peut donc rouvrir directement la même sélection. Le nombre de mots fournit aussi une estimation de durée de lecture sur la base de 220 mots par minute.
Enrichir la lecture sans modifier les articles un par un.
Un composant commun analyse les titres de niveau deux et trois présents dans la page afin de construire une table des matières. Il calcule le temps de lecture, permet de copier le lien et propose jusqu'à trois articles partageant des tags. Ces fonctions sont ajoutées autour du contenu MDX : l'auteur peut donc se concentrer sur l'article sans recoder la navigation ou les recommandations pour chaque publication.
Développer un formulaire validé dans le navigateur et sur le serveur.
Le formulaire de contact repose sur React Hook Form pour gérer les champs et sur Zod pour décrire les règles : longueur du nom et du message, adresse électronique valide, motif obligatoire et sujet libre lorsque l'option « autre » est choisie. La même règle est rejouée par une Server Action, une fonction Next.js exécutée sur le serveur. Cette double validation donne un retour rapide à l'utilisateur sans faire confiance aux données reçues par le serveur. Les valeurs sont échappées avant d'être insérées dans l'e-mail pour empêcher qu'un message soit interprété comme du code HTML.
Choisir Resend pour remettre les messages.
Je recherchais un service disposant d'un palier gratuit et simple à intégrer avec Next.js. Resend reçoit le nom, l'adresse, le motif et le message validés, puis envoie un e-mail à mon adresse de contact avec l'adresse du visiteur comme reply-to. L'interface distingue explicitement la réussite de l'échec et permet de recommencer un envoi. Les clés, l'expéditeur et le destinataire restent dans des variables d'environnement, c'est-à-dire des valeurs de configuration absentes du code public.
Ajouter toutes les protections anti-spam dans le même sprint.
Un sprint désigne ici une courte période de travail consacrée à un ensemble cohérent de fonctions. J'ai combiné quatre contrôles : un honeypot, champ invisible que les robots remplissent souvent ; un délai minimum de trois secondes entre l'affichage et l'envoi ; une limite de cinq tentatives par heure et par adresse IP ; et reCAPTCHA v3, qui attribue un score de comportement lorsqu'il est configuré. La limite est désormais atomique et partagée entre les instances serverless grâce à Redis ; l'adresse IP est hachée avant stockage et la production refuse l'envoi si cette protection durable n'est pas configurée.
Créer moi-même le bandeau de consentement.
Je n'ai pas installé une plateforme externe : le composant propose « tout accepter », « tout refuser » et la gestion détaillée. Il distingue les cookies nécessaires au fonctionnement — langue et thème — de la mesure d'audience facultative. Le choix est enregistré localement et un événement prévient immédiatement le composant d'analytics. Google Tag Manager ou Google Analytics ne sont injectés qu'après accord pour cette catégorie, ce qui traduit techniquement le principe de consentement du RGPD, le règlement européen protégeant les données personnelles.
Mettre en place les fondations de visibilité et de sécurité.
Les métadonnées sont traduites et déclarent une adresse canonique, les variantes française et anglaise, les aperçus Open Graph et les règles d'indexation. Un sitemap liste les pages, articles, projets, compétences et réalisations dans les deux langues ; robots.txt indique aux moteurs de recherche les zones explorables. Des données structurées Schema.org décrivent la personne, le site et la page de profil. Enfin, des en-têtes de sécurité limitent les sources de scripts, empêchent l'intégration du site dans une iframe étrangère et réduisent les permissions accordées au navigateur.
Relier les preuves publiques aux affirmations du portfolio.
La page d'accueil propose des liens directs vers le CV, le TOEIC et les diplômes placés dans le dossier public. Ces documents s'ouvrent séparément afin que l'examinateur puisse les consulter sans perdre sa position. La présence de chaque lien public est couverte par un test. Pour les réalisations professionnelles, je prépare en revanche des captures anonymisées et les fais valider avant publication afin de ne pas exposer les données de l'entreprise.
Construire plusieurs niveaux de tests.
Vitest et React Testing Library vérifient les fonctions et composants isolés : règles de langue, formulaire, anti-spam, consentement, recherche, navigation et réciprocité des liens. Le mode navigateur de Vitest utilise Chromium pour contrôler les comportements réels et certaines captures visuelles, notamment le formulaire, le bandeau de cookies et le sélecteur de langue. Playwright exécute des tests de bout en bout, ou E2E, qui parcourent l'application construite comme le ferait un visiteur. Cette combinaison couvre à la fois la logique rapide à tester et les parcours où plusieurs couches interagissent.
Automatiser les contrôles avec GitHub Actions.
À chaque pull request ou envoi sur la branche principale, le pipeline installe exactement les dépendances verrouillées avec pnpm. Il lance le lint, qui détecte les écarts de qualité statique, les tests unitaires, les tests de composants dans Chromium et la construction de production. Après un build réussi, les scénarios Playwright sont exécutés et leur rapport est conservé en cas de diagnostic. CI signifie intégration continue : le dépôt vérifie automatiquement qu'un changement peut rejoindre la version commune. Le déploiement continu est ensuite pris en charge par Vercel à partir de la version validée.
Itérer par petits changements vérifiables.
Les pages et fonctions n'ont pas été écrites en une seule fois. Après la première version complète, j'ai ajouté les projets Odoo, les fiches de compétences et de réalisations, puis une refonte visuelle, les preuves, la recherche d'articles et les tests associés. Chaque étape peut être relue dans l'historique Git, qui enregistre les versions successives du code. Cette progression limite la taille des corrections et permet de vérifier le résultat en local avant de publier.
Enrichir les textes à partir de faits, puis les relire humainement.
J'ai d'abord listé ce que chaque section devait expliquer. Je me suis ensuite servi de l'intelligence artificielle pour générer des questions auxquelles je n'aurais pas pensé, puis pour structurer une première rédaction à partir de mes réponses. Cette assistance ne constitue pas une preuve et ne décide pas de mon expérience : je relis manuellement chaque passage, corrige les approximations de transcription orale et retire toute formulation qui ne correspond pas à ce que j'ai réellement fait.
Faire de la conformité éditoriale une étape de développement.
La liste Markdown n'est pas un document figé : je la mets à jour lorsque les articles, liens, preuves ou niveaux de détail évoluent. Les tests protègent les relations structurelles, mais ils ne peuvent pas juger seuls si une anecdote est assez claire ou si mon regard critique est sincère. La validation finale associe donc le contrôle automatique, une relecture orthographique, ma propre relecture du sens et le retour du learning coach sur l'adéquation avec les attentes des examinateurs.
Préparer une version réellement prête à être évaluée.
La prochaine étape n'est pas l'ajout d'animations décoratives. Je dois faire valider le contenu par mon learning coach, exécuter des tests approfondis de toutes les fonctionnalités et stabiliser le pipeline CI/CD avant de considérer le site comme terminé. Cette définition de fini inclut le formulaire, le responsive, les thèmes, les langues, les liens, les preuves et les articles. Elle permet de distinguer une page qui « semble complète » d'un produit contrôlé et présentable à un examinateur ou à un recruteur.

Retour au sommaire

Les acteurs — les interactions

Un projet personnel dont je reste le responsable principal.
J'assure seul la conception technique, le développement, le design final, la rédaction, les tests, le déploiement et la maintenance du portfolio. Cette responsabilité ne signifie pas que le projet a été réalisé sans interactions : plusieurs personnes influencent sa conformité, sa lisibilité ou la publication de certaines preuves. Je reste cependant propriétaire des arbitrages et de la version finalement mise en ligne.
Le learning coach comme garant des attentes du titre.
Son rôle principal est de vérifier que le portfolio répond aux attendus du titre préparé. Il ne développe pas le site et ne rédige pas les articles à ma place. Il confronte le contenu et la structure à la grille d'évaluation afin d'identifier ce qu'un examinateur pourrait considérer comme absent, trop superficiel ou difficile à trouver. Son regard apporte donc une validation pédagogique complémentaire à mes contrôles techniques.
Quatre ou cinq points de contrôle pendant la réalisation.
J'ai présenté l'avancement à mon learning coach à environ quatre ou cinq reprises. Ces échanges répétés permettent de corriger le projet pendant sa construction plutôt que d'attendre l'évaluation finale. Chaque présentation constitue un point de contrôle : je montre l'état réel du site, il formule ses remarques, puis je décide comment les convertir en modifications de contenu ou d'interface.
Un accompagnement portant à la fois sur le fond et sur la forme.
Les retours du learning coach ne se limitent pas à cocher les critères de la grille. Ils concernent aussi la structure des pages, l'ordre des informations et la quantité de rédaction nécessaire pour qu'un examinateur comprenne réellement mon travail. Cette double lecture est importante : une information peut exister dans le code ou dans une page, mais rester inefficace si elle apparaît trop tard, manque d'explications ou n'est pas accessible par la navigation attendue.
Un premier retour ayant déclenché l'approfondissement des articles.
Le learning coach m'a indiqué que les compétences et les réalisations n'étaient pas assez rédigées. Une liste de technologies ou quelques phrases ne suffisent pas à démontrer un niveau d'expertise : il faut expliquer le contexte, les décisions, les interactions, les résultats et le recul acquis. Ce retour est à l'origine du travail d'entretien détaillé mené pour chaque réalisation et de la transformation de réponses brutes en articles structurés. L'objectif n'est pas d'allonger artificiellement les pages, mais de rendre les raisonnements et la valeur ajoutée vérifiables.
Un second retour ayant modifié la hiérarchie de la page d'accueil.
Mon learning coach estimait que la section « Mon parcours » apparaissait trop bas. Je l'ai donc remontée immédiatement après la présentation et avant les compétences et les réalisations. Ce changement permet à un nouveau lecteur de comprendre plus tôt la chronologie de ma formation et de mes expériences avant d'examiner ce que je sais faire. L'historique Git conserve un commit consacré à cette réorganisation, ce qui relie directement l'interaction au changement réalisé.
Les collègues de travail comme premiers regards extérieurs.
Des collègues ont consulté le portfolio et mes essais d'interface. Leur connaissance du contexte professionnel leur permet de repérer si l'image renvoyée paraît cohérente avec mon activité et si la présentation reste crédible. Ils n'interviennent pas comme décideurs techniques : leurs réactions me donnent des informations supplémentaires sur la perception du site, puis je choisis les corrections pertinentes.
Les proches comme testeurs informels de l'interface.
Des proches ont également parcouru le site et vu certaines propositions réalisées dans Figma. Un testeur informel n'exécute pas un protocole écrit avec des mesures : il utilise l'interface librement et exprime ce qu'il comprend, apprécie ou trouve perfectible. Leurs retours ont confirmé que le design général était convaincant et ont fait émerger des conseils d'amélioration de l'interface. Je n'attribue toutefois pas à ces échanges une précision qu'ils n'avaient pas : il s'agissait de retours qualitatifs, pas d'une étude d'utilisabilité complète.
Figma comme support de discussion avant le code final.
J'ai montré à des collègues et à des proches mes essais Figma, c'est-à-dire des représentations visuelles permettant de tester une direction graphique avant ou pendant son intégration. Ils pouvaient ainsi commenter la hiérarchie, les composants et l'impression générale sans devoir interpréter le code. Cette étape aide à distinguer un désaccord sur le rendu d'un problème purement technique d'implémentation.
Une validation de compréhension par un public novice encore à réaliser.
Je n'ai pas encore demandé à une personne ne connaissant ni Odoo ni mon parcours de lire intégralement une fiche de compétence ou de réalisation. Cette vérification est pourtant nécessaire, puisque l'examinateur ou le recruteur peut ne pas connaître l'ERP. Je prévois donc un test de lecture où la personne devra reformuler le problème, mon rôle, le résultat et les termes principaux. Les incompréhensions permettront d'identifier les notions encore insuffisamment définies. Je présente cette étape comme prévue et non comme déjà accomplie.
Les examinateurs et recruteurs comme publics cibles, pas comme coauteurs.
Les examinateurs n'interviennent pas directement pendant le développement : leurs attentes sont représentées par la grille et par les retours du learning coach. Les recruteurs sont un second public cible, notamment grâce à la version anglaise, mais aucun recruteur n'a encore participé à une session formelle de test. Cette distinction évite de transformer une intention de conception en interaction qui n'a pas eu lieu.
Un arbitrage final qui reste de ma responsabilité.
Lorsque plusieurs conseils divergent ou qu'un retour ne correspond pas à la direction recherchée, je prends la décision finale. J'essaie d'abord de satisfaire tous les éléments exigés pour le diplôme. Une fois ce socle assuré, j'ajoute les fonctions qui m'intéressent personnellement — bilinguisme, blog, animations, thème ou recherche — lorsqu'elles apportent aussi une valeur au visiteur. Cette règle me permet de conserver une identité personnelle sans sacrifier un critère évalué.
Le directeur général comme autorité sur les preuves de l'entreprise.
Les captures d'écran, extraits ou informations issus des projets de mon employeur ne peuvent pas être publiés par ma seule décision. Je présente littéralement au directeur général le contenu que je souhaite utiliser, déjà anonymisé lorsque cela est nécessaire. Il peut l'autoriser, le refuser ou demander une modification. Ce contrôle protège les clients, les données internes, le code appartenant à l'entreprise et l'image de la société ; il délimite donc ce que je peux prouver publiquement sans remettre en cause la réalité du travail présenté.
L'intelligence artificielle comme assistance éditoriale importante.
L'intelligence artificielle occupe une place notable dans la préparation des textes, car l'entretien, la reformulation et la traduction de contenus aussi volumineux sont chronophages. Je l'utilise pour produire des questions, organiser mes réponses et accélérer une première passe. Mes réponses, le code, l'historique Git et les preuves validées restent toutefois les sources. Je relis le résultat pour corriger les erreurs de transcription et empêcher qu'une formulation plausible remplace un fait.
Des fonctionnalités principales que je ne délègue pas à l'IA.
Je ne délègue pas la conception et la réalisation intégrales des fonctions essentielles du portfolio. Si l'outil décidait seul de l'architecture, de la navigation, du formulaire ou du modèle de contenu, le projet ne démontrerait plus correctement mes compétences. L'assistance peut m'aider à comprendre, vérifier ou accélérer une tâche, mais je dois être capable d'expliquer les choix, de relire le code, d'exécuter les tests et d'assumer le comportement publié.
Une boucle d'interaction simple et traçable.
Le fonctionnement général suit quatre temps : je prépare une version, je la montre à la personne pertinente, je recueille le retour, puis je décide et j'implémente. Le learning coach intervient sur la conformité et la structure, les collègues et proches sur la perception de l'interface, et le directeur général sur l'autorisation des preuves professionnelles. Cette répartition évite de demander une décision technique à une personne qui n'en porte pas la responsabilité, tout en intégrant les regards nécessaires avant l'évaluation et la publication.

Retour au sommaire

Les résultats

Un produit réellement publié sur un domaine personnel.
Le portfolio est accessible publiquement sur orhanmadiassani.com et ne reste donc pas limité à une démonstration locale. Un domaine personnalisé fournit une adresse stable, plus simple à communiquer dans un CV ou à un recruteur qu'une URL technique d'hébergement. La version française est disponible sous /fr et la version anglaise sous /en ; le visiteur peut passer de l'une à l'autre sans revenir à la page d'accueil.
L'objectif initial de présentation du profil est atteint.
Je considère que le site permet désormais à une personne souhaitant me connaître professionnellement de consulter les informations principales : présentation générale, projet professionnel et personnel, parcours, compétences, réalisations, articles, projets open source, preuves et moyens de contact. Le résultat ne dépend donc pas d'une seule page spectaculaire. Il repose sur plusieurs niveaux de lecture, depuis la synthèse de la page d'accueil jusqu'aux articles détaillés.
Un socle fonctionnel complet au-delà d'une page de présentation.
Le code contient dix compétences comparées, cinq réalisations, 6 articles publiés et les expériences de mon parcours dans les deux langues d'interface. Les relations entre compétences et réalisations sont navigables dans les deux sens. La dernière construction de production a généré 109 pages ou variantes de routes, notamment pour les langues et les fiches de détail. Ce volume montre que le résultat est devenu une petite application éditoriale structurée plutôt qu'un CV statique mis en ligne.
Une conformité pédagogique déjà largement reconnue.
Après environ quatre ou cinq présentations, le learning coach considère que la quasi-totalité des éléments attendus est présente. Il me demande de continuer la rédaction, car la faiblesse restante ne concerne plus principalement l'existence des pages ou des fonctions, mais la profondeur des contenus consacrés aux compétences et aux réalisations. Cette validation reste un retour d'accompagnement et non la note finale d'un jury ; je ne la présente donc pas comme une certification déjà obtenue.
Deux familles de contenus encore à approfondir.
Les compétences et les réalisations restent les parties qui empêchent de considérer le portfolio éditorialement terminé. Leur structure, leurs liens et leurs rubriques existent, mais chaque explication doit permettre à une personne extérieure de comprendre le contexte, mon rôle, le résultat et mon recul. Le travail actuel consiste donc moins à ajouter de nouvelles fonctions qu'à remplacer les formulations trop courtes par des démonstrations utiles et factuelles.
Un audit Lighthouse réalisé sur toute la production.
Le 16 juillet 2026, j'ai lancé Lighthouse avec le profil mobile de Chrome sur les 100 URL du sitemap public, en français et en anglais. Les moyennes sont de 94,3 sur 100 en performance, 99,8 en accessibilité, 99,9 en bonnes pratiques et 100 en SEO. Les 100 pages ont un CLS de 0, c'est-à-dire qu'aucun déplacement visuel cumulé n'a été relevé pendant la mesure. Lighthouse est un outil d'audit automatisé intégré aux outils de développement de Chrome ; il fournit un point de comparaison reproductible, mais pas l'expérience exacte de chaque visiteur.
Une performance élevée sur 98 pages, avec une exception clairement identifiée.
98 des 100 pages atteignent au moins 90 en performance ; la médiane est de 96. Le FCP médian, qui mesure la première apparition de contenu, est de 1,08 s ; le LCP médian, qui mesure l'affichage du contenu principal, est de 2,49 s ; le TBT médian est de 44 ms. Les deux exceptions sont les versions française et anglaise de la réalisation App Trajectoires de vie : elles obtiennent 57, avec un FCP de 8,63/8,72 s et un LCP de 9,53/12,24 s. Cette mesure donne donc un résultat concret à la fois sur la solidité générale du site et sur le point qui reste prioritaire.
Les lecteurs YouTube de la réalisation CAP2vie deviennent la priorité performance.
Les quatre lecteurs YouTube chargés directement sur cette réalisation expliquent l'essentiel du ralentissement et déclenchent aussi une alerte Cookies dans Chrome. Remplacer ces iframes par un aperçu léger activé au clic, puis créer le lecteur seulement après consentement et interaction, doit améliorer le chargement initial tout en limitant le chargement d'un service tiers. L'audit a aussi relevé environ 25 KiB économisables sur l'image décorative Fuji, 25 KiB de JavaScript inutilisé et environ 150 ms de CSS bloquant : ces optimisations sont utiles, mais secondaires par rapport aux vidéos.
Une accessibilité très élevée, avec deux corrections précises à livrer.
La moyenne atteint 99,8 sur 100 ; quatre pages restent à 96. Sur les accueils français et anglais, le CTA des réalisations affiche du texte blanc sur un fond #ff5444 avec un contraste de 3,18:1 au lieu du minimum de 4,5:1. Sur les listes d'articles française et anglaise, les boutons de tags ne mesurent qu'environ 22 px de haut au lieu des 24 px requis. Ces constats donnent des corrections concrètes à effectuer ; ils ne dispensent pas des essais au clavier, avec lecteur d'écran et avec la préférence de réduction des mouvements.
Le SEO est à 100 sur les 100 pages et les bonnes pratiques à 100 sur 98 d'entre elles.
La catégorie « bonnes pratiques » vérifie une sélection de règles liées aux erreurs du navigateur, à la sécurité et à l'usage correct des API Web. Les deux pages CAP2vie sont à 96 à cause de l'alerte liée aux cookies des lecteurs YouTube ; toutes les autres obtiennent 100. Le SEO, ou référencement naturel, est à 100 sur l'ensemble du sitemap : ce résultat confirme la qualité des contrôles couverts par Lighthouse, sans garantir une sécurité absolue ni une première position dans les résultats de recherche.
Des mesures datées à rejouer après les corrections.
Le rapport détaillé conserve les quatre scores et les métriques FCP, LCP, TBT et CLS pour chaque URL. Il a été obtenu avec une mesure de laboratoire mobile par page ; l'appareil, le réseau, le cache ou un service externe peuvent faire varier le résultat. Je dois donc rejouer l'audit complet après le remplacement des lecteurs YouTube et après toute évolution importante du frontend. Cette méthode est plus crédible qu'un score isolé, car elle vérifie la production sur toutes ses routes publiques.
Une compréhension plus poussée du RGPD.
Le Règlement général sur la protection des données encadre la collecte et l'utilisation des données personnelles. Ce projet m'a obligé à aller plus loin que sur mes réalisations précédentes : distinguer les fonctions nécessaires des statistiques facultatives, permettre l'acceptation comme le refus, conserver le choix et ne charger l'outil de mesure qu'en fonction du consentement prévu. Le résultat est une architecture de consentement plus réfléchie. Je ne transforme toutefois pas cet apprentissage en certification juridique : l'absence de problème de conformité doit rester contrôlée à chaque évolution.
Des statistiques de consultation effectivement disponibles.
L'intégration analytics fonctionne et me fournit déjà des données sur l'utilisation du site. Analytics désigne les mesures permettant d'observer, par exemple, les pages consultées ou la circulation entre les contenus. Je n'ai pas fourni ici de chiffres suffisamment consolidés pour démontrer une audience ou une conversion ; je me limite donc au résultat vérifiable que la collecte consentie produit des données. L'intérêt futur sera d'identifier les pages réellement lues et celles qui restent difficiles à découvrir.
Un formulaire dont la chaîne d'envoi a été validée par mes essais.
Les messages saisis pendant mes tests ont bien parcouru le formulaire, la validation serveur et Resend jusqu'à la boîte destinataire. Resend est le service chargé de remettre l'e-mail après validation des données et des protections anti-spam. Ce résultat prouve le fonctionnement technique du parcours. Il ne constitue pas encore un résultat commercial : aucun visiteur extérieur ne m'a contacté par ce moyen pour le moment.
Des retours extérieurs positifs, mais encore limités au design.
Mes collègues et mes proches apprécient le rendu visuel du portfolio. Ce retour confirme que la direction graphique produit l'impression professionnelle recherchée. Il reste qualitatif et informel : je n'ai pas recueilli de note, conduit de protocole d'utilisabilité ni comparé plusieurs variantes auprès d'un échantillon. Aucun recruteur ou examinateur n'a encore évalué le site, ce qui empêche de conclure que la présentation produit déjà un effet mesurable sur ces publics.
Une qualité du code protégée par plus de 140 tests automatisés.
La suite actuelle couvre 21 fichiers de tests et vérifie notamment les langues, la navigation, le contact, l'anti-spam, le consentement, la recherche d'articles, les preuves et les relations circulaires. La construction Next.js passe également la vérification TypeScript et génère la version de production. Ce résultat réduit le risque qu'une modification éditoriale casse silencieusement une fonction existante. Il ne supprime pas la nécessité de tester visuellement le responsive, le thème et les parcours complets dans un navigateur.
Un apprentissage technique marqué par l'accessibilité et la conformité.
Le projet m'a fait travailler des sujets que j'avais moins approfondis auparavant : consentement, protection des données, sémantique des pages, préférences de mouvement, navigation au clavier, métadonnées et politiques de sécurité. Cette progression dépasse l'intégration graphique. Elle m'a appris à considérer un site comme un produit destiné à de vrais visiteurs, avec des responsabilités qui commencent avant le développement et continuent après la mise en ligne.
Une meilleure capacité à structurer un contenu professionnel long.
J'ai appris à transformer une expérience en page Web lisible : annoncer le contexte, séparer les enjeux des étapes, mettre en évidence les résultats et terminer par une autocritique. Cette organisation est différente d'un compte rendu brut ou d'une liste de technologies. Elle doit permettre une lecture rapide par les titres et les caractères gras, puis une lecture approfondie lorsque l'examinateur souhaite vérifier le raisonnement.
Une meilleure connaissance de mes forces et de mon axe de progrès.
Le portfolio met en évidence ma capacité à réaliser une interface complète et cohérente, mais il révèle aussi un point que je veux améliorer : produire davantage de code réutilisable. Un composant réutilisable isole une structure ou un comportement commun afin de l'employer à plusieurs endroits sans le recopier. Cette prise de recul est déjà un résultat du projet, car elle transforme une préférence générale pour le clean code en objectif précis d'architecture.
Un niveau actuel représenté par le frontend et les intégrations de services.
La partie qui reflète le mieux mon niveau dans ce portfolio est le frontend : design responsive, composants, animations, langues, thèmes et accessibilité. Elle est complétée côté serveur par l'intégration de Resend et des protections du formulaire. Sanity, le système de gestion de contenu que j'ai cité dans ma réponse, appartient au site corporate présenté dans une autre réalisation et non au code de ce portfolio. Ensemble, ces projets illustrent ma capacité à relier une interface soignée à des services externes sans confondre leurs périmètres.
Une réussite finale définie par le design et la conformité.
Je considérerai la réalisation complètement réussie lorsque le résultat visuel atteindra le niveau « top notch » recherché, c'est-à-dire un design particulièrement abouti et cohérent, et qu'aucun écart de conformité connu ne subsistera. Cette définition implique la fin de l'approfondissement des compétences et réalisations, une relecture par un public novice, la validation du learning coach, la vérification des preuves et le maintien des contrôles techniques. Le succès ne se réduit donc ni à la mise en ligne ni à un score Lighthouse isolé.

Retour au sommaire

Les lendemains du projet

Un contrôle complet avant la présentation au jury.
La suite immédiate consiste à reprendre la grille critère par critère et à vérifier le résultat réellement visible, pas seulement la présence d'une donnée dans le code. Ce contrôle couvrira l'identité et la navigation sur toutes les pages, la profondeur des articles, les liens circulaires, le parcours, les preuves, le contact, l'orthographe et les traductions. Je veux pouvoir relier chaque point demandé à une page et à un élément précis plutôt que supposer que l'examinateur le trouvera.
Une première version finalisée en août 2026.
Je vise le mois d'août pour terminer la version destinée à l'évaluation. Cette échéance ne signifie pas que le site sera définitivement figé : elle fixe une version de référence dans laquelle tous les attendus connus auront été contrôlés. Les fonctions facultatives qui ne sont pas suffisamment maîtrisées ne doivent pas retarder cette finalisation.
La rédaction des compétences et réalisations comme priorité immédiate.
Les retours du learning coach indiquent que le principal travail restant concerne la profondeur du contenu. Je dois donc terminer les rubriques encore trop brèves, définir les notions spécialisées et vérifier que chaque anecdote démontre réellement une compétence ou un résultat. Cette priorité passe avant l'ajout de nouveaux effets ou services, car une fonction supplémentaire ne compenserait pas un critère éditorial incomplet.
Une validation finale combinant plusieurs regards.
Avant l'évaluation, je prévois un nouveau contrôle avec le learning coach et une lecture par une personne qui ne connaît ni Odoo ni mon parcours. Le premier vérifiera l'alignement avec le titre ; la seconde devra pouvoir reformuler le problème, mon rôle et le résultat sans explication orale supplémentaire. Ces deux validations répondent à des risques différents : manquer un attendu officiel et écrire un contenu compréhensible uniquement par son auteur.
Un projet maintenu après l'obtention du titre.
Je continuerai à faire évoluer le portfolio après l'évaluation, notamment parce que j'apprécie concevoir de nouvelles interfaces. Le diplôme constitue une étape de livraison, pas la fin du produit. Cette continuité permettra au site de suivre mon niveau réel au lieu de conserver indéfiniment la photographie de mon profil en août 2026.
Une maintenance déclenchée par les évolutions professionnelles.
Je ne prévois pas une réécriture à date fixe. Je mettrai le contenu à jour lorsque ma situation professionnelle changera : nouvelle responsabilité, mission significative, compétence mieux maîtrisée, réalisation publiable, certification ou évolution de poste. Cette maintenance événementielle évite des modifications artificielles tout en réduisant le risque qu'un recruteur lise une information devenue obsolète.
Des formulations datées à réexaminer régulièrement.
Les versions d'Odoo, le nombre d'articles, mon niveau déclaré, mes objectifs et les expressions comme « actuellement » peuvent rapidement devenir incorrects. Lors de chaque évolution, je devrai rechercher ces informations dans les versions française et anglaise, mettre à jour les relations concernées et rejouer les tests. Le bilinguisme impose en particulier de ne pas actualiser une seule langue.
La poursuite d'un blog centré sur le développement.
Je souhaite continuer à publier des articles techniques, notamment sur Odoo. Les sujets viendront de problèmes réellement rencontrés, de solutions difficiles à trouver dans la documentation ou d'explications susceptibles d'aider un autre développeur. Le blog doit ainsi faire vivre le site tout en transformant mon expérience en connaissance réutilisable, plutôt que publier selon un calendrier sans contenu pertinent.
Une participation durable à la communauté des développeurs.
À long terme, les articles et les modules open source doivent permettre au portfolio de produire autre chose qu'une présentation personnelle. Open source signifie que le code est rendu publiquement accessible selon les conditions de sa licence afin que d'autres puissent l'étudier ou le réutiliser. Documenter une résolution, publier une version générique d'un module et expliquer ses limites constitue une manière concrète de contribuer aux ressources disponibles en ligne.
Des analytics utilisés pour comprendre l'audience de manière agrégée.
Je consulterai les statistiques pour savoir quelles catégories de visiteurs arrivent sur le site, quelles pages ils ouvrent et combien de temps ils y restent. Il ne s'agit pas d'identifier nominativement une personne. Les données agrégées regroupent les comportements de plusieurs visites afin d'observer des tendances sans prétendre connaître chaque individu. Elles pourront indiquer qu'une réalisation importante est peu découverte ou qu'une page est quittée avant les informations essentielles.
Une accessibilité à faire progresser à partir de défauts identifiés.
L'audit complet montre une moyenne de 99,8, mais quatre pages sont à 96. Je dois corriger le contraste du CTA des réalisations sur les deux accueils et donner aux tags des listes d'articles une cible tactile d'au moins 24 px. Lighthouse fournit la catégorie Accessibilité et indique ces points précis ; je la compléterai par la navigation au clavier, la vérification du focus, des libellés, des contrastes et de la préférence de réduction des mouvements. L'objectif n'est pas seulement de gagner quelques points, mais de supprimer un obstacle réel lorsqu'il est identifié.
Des performances suivies page par page avec les outils adaptés.
L'audit de production fixe une référence : 98 pages à au moins 90, un LCP médian de 2,49 s et deux pages à 57 à cause des lecteurs YouTube. L'onglet Performance des outils de développement Chrome reste pertinent pour enregistrer l'activité de la page et comprendre le coût d'un script, d'une animation ou d'un rendu ; Lighthouse permet ensuite de comparer les quatre catégories sur l'ensemble du sitemap. Après le remplacement des lecteurs et après une modification importante du frontend, je rejouerai les deux contrôles pour vérifier le gain et éviter une régression sur une autre route.
Un design encore à professionnaliser.
Malgré les retours positifs et les scores techniques, je considère que l'interface n'atteint pas encore complètement le niveau professionnel recherché. Le travail futur portera d'abord sur la cohérence de la hiérarchie, des espacements, des composants et des détails responsives plutôt que sur l'accumulation d'animations. Un design « top notch » devra paraître abouti sur l'ensemble des pages, pas seulement dans le hero de la page d'accueil.
Des composants frontend à rendre plus réutilisables.
Je veux mieux isoler les structures communes utilisées dans les pages, les cartes, les métadonnées, les sections narratives et les états interactifs. Un composant réutilisable reçoit des données et applique un comportement cohérent sans recopier la même structure. Cette évolution doit réduire les divergences entre pages françaises et anglaises, faciliter les changements de design et rendre les tests plus ciblés.
Un découpage du fichier central désormais réalisé.
Les cinq études de cas disposent maintenant chacune de leur propre module TypeScript. Un fichier contient les types partagés et realisations.ts ne conserve plus que les imports, la liste ordonnée et la fonction de recherche publique. Le contenu a été comparé avant et après le découpage au moyen d'une empreinte calculée sur toutes les données sérialisées : elle est restée identique. Chaque article peut donc être modifié et relu isolément sans changer les imports utilisés par les pages et les tests.
La maîtrise de l'existant avant toute nouvelle fonctionnalité.
Je n'ai pas encore décidé des fonctions qui suivront la version évaluée. Ce choix est volontaire : je veux d'abord comprendre, vérifier et maintenir correctement le bilinguisme, les animations, le blog, les analytics, le consentement, le contact et les tests déjà présents. Une nouveauté ne sera pertinente que si elle répond à un besoin identifiable et si je peux en assumer la maintenance.
Un laboratoire pour expérimenter de nouvelles technologies.
Après stabilisation, le portfolio pourra rester un terrain d'essai pour de nouveaux choix d'interface, outils ou pratiques Web. Un laboratoire technique autorise l'expérimentation, mais la branche publique doit rester stable : une idée sera d'abord isolée et testée avant de remplacer un comportement existant. Cette séparation permet de continuer à apprendre sans transformer la vitrine professionnelle en démonstration instable.
Une veille sur la conformité et les recommandations officielles.
Je prévois de refaire des audits et de consulter les nouveautés publiées par les organismes publics compétents. La veille consiste à suivre les changements de règles, de référentiels et de recommandations susceptibles d'affecter le site. Pour la protection des données, les publications de la CNIL constituent une référence française ; pour l'accessibilité, les évolutions des référentiels publics doivent aussi être surveillées. Une nouveauté réglementaire devra être traduite en contrôle concret dans le code ou le contenu.
Des contrôles fonctionnels récurrents.
Après une mise à jour, je vérifierai les liens internes et les documents, les deux langues, le responsive, les thèmes, le consentement, les analytics et l'envoi du formulaire. Les tests automatisés couvrent une partie de ces éléments, mais un essai réel reste nécessaire pour les services externes et la perception visuelle. Si l'hébergement ou un service devenait durablement indisponible, l'application Next.js pourrait être redéployée sur une autre plateforme à partir du dépôt et de ses variables d'environnement documentées.
Trois rôles durables pour le portfolio.
À long terme, le site doit rester une palette technique, c'est-à-dire un espace où plusieurs compétences et technologies sont démontrées par des réalisations concrètes. Il doit également présenter fidèlement mon profil lorsque ma situation évolue et me permettre de participer à la communauté du développement par les articles et les projets open source. Ces trois fonctions — expérimenter, présenter et contribuer — donnent au projet une utilité au-delà de l'évaluation du diplôme.

Retour au sommaire

Mon regard critique

Avoir voulu animer le site trop tôt.
Ma principale erreur a été de commencer les animations avant d'avoir stabilisé le contenu et la structure des pages. Une animation donne rapidement l'impression d'avancer parce que son résultat est visible, mais elle dépend de la taille des blocs, de leur ordre et du message qu'ils portent. Lorsque ces éléments changent ensuite, l'effet doit être ajusté ou supprimé. J'ai donc investi du temps dans une couche de finition alors que la matière qu'elle devait accompagner n'était pas encore suffisamment définie.
Avoir pensé le design avant la quantité réelle de texte.
J'aurais dû rédiger les contenus principaux, ou au moins établir leur volume et leur hiérarchie, avant de figer les choix visuels. Une carte conçue pour trois lignes ne fonctionne plus de la même manière lorsqu'elle reçoit plusieurs paragraphes ; une page de réalisation détaillée n'a pas les mêmes besoins qu'une courte vitrine. En inversant cet ordre, je me suis parfois retrouvé à adapter le texte au design alors que l'interface devait servir le contenu évalué.
Un ordre de travail à reconstruire autour de la priorité.
Le séquencement le plus efficace aurait été : d'abord la grille et les contenus indispensables, ensuite les composants réutilisables et la navigation, puis les tests des parcours principaux, et enfin les animations et raffinements. J'ai parfois traité une fonction plaisante avant un besoin noté. Cette expérience m'a appris que la priorité ne dépend pas de l'intérêt technique d'une tâche, mais de son importance pour l'objectif du produit.
Un blog probablement développé trop tôt.
Le blog apporte une valeur durable au portfolio et à la communauté, mais il n'était pas indispensable pour satisfaire les premiers critères d'évaluation. Sa structure MDX, la recherche, les tags, le temps de lecture, la table des matières et les recommandations ont demandé un investissement conséquent. Au regard du temps libre dont je dispose, une partie de cet effort aurait pu être reportée après la rédaction complète des compétences et réalisations.
Un périmètre trop ambitieux par rapport au temps disponible.
Bilinguisme, blog, animations, analytics, consentement, contact, recherche, thème, preuves et plusieurs niveaux de tests forment un produit intéressant, mais vaste pour un projet mené sur le temps personnel. Le problème ne vient pas de chaque fonction prise séparément ; il vient de leur accumulation avant la fermeture du socle obligatoire. J'aurais dû définir plus strictement une première version évaluée, puis ajouter les enrichissements par étapes.
Des animations parfois ajoutées avant la valeur éditoriale.
Oui, certains effets ont été créés alors que les textes essentiels restaient incomplets. Ils ne sont pas nécessairement mauvais et plusieurs restent discrets, mais leur timing de développement était incorrect. Une animation doit renforcer une hiérarchie déjà claire, signaler une transition ou améliorer la compréhension. Lorsqu'elle précède le contenu, elle risque de masquer un problème de structure au lieu de le résoudre.
Des contenus longs qui exigent une architecture éditoriale dédiée.
Le volume des réalisations reste important même après le découpage des fichiers. Le problème n'est plus de trouver l'article dans un fichier central, mais de conserver une lecture humaine malgré plusieurs dizaines de points par étude de cas. J'ai donc ajouté un sommaire responsive, des ancres, de vrais sous-titres numérotés, une largeur de ligne limitée et des retours au sommaire. Cette solution améliore la consultation sans masquer ni supprimer les développements demandés par la grille.
Un modèle de données TypeScript désormais découpé.
Stocker les réalisations dans des objets typés reste utile pour produire des pages cohérentes, des liens vérifiables et un rendu commun. Mon erreur a été de laisser les cinq objets grandir dans le même fichier jusqu'à dépasser 790 Ko. Le découpage par réalisation corrige cette dette sans abandonner le typage ni dupliquer les fonctions d'accès. Je referais cette séparation plus tôt, dès que le contenu éditorial commence à représenter l'essentiel du poids d'un module.
Des interfaces de cartes insuffisamment mutualisées.
Plusieurs pages utilisent des cards, ou cartes d'interface, pour présenter une compétence, une réalisation, un article, une preuve ou un projet. J'aurais dû identifier plus tôt leurs éléments communs : en-tête, badges, résumé, métadonnées, action et comportement responsive. Une base de carte configurable aurait réduit les répétitions tout en autorisant des variantes. La réutilisation ne signifie pas rendre toutes les cartes identiques, mais partager ce qui relève réellement du même comportement.
Un design que je juge encore trop classique.
Le rendu est cohérent et reçoit des retours positifs, mais je ne le trouve pas encore assez maîtrisé ni suffisamment professionnel. Certaines solutions visuelles restent proches de conventions courantes de portfolios techniques sans produire une identité assez forte. Mon insatisfaction ne justifie pas de tout recommencer : elle indique qu'il faut améliorer la hiérarchie, les proportions, les espacements et la cohérence entre les pages avant d'ajouter davantage d'effets.
Une couverture d'intégration encore à renforcer.
Un test d'intégration vérifie que plusieurs parties réelles du système fonctionnent ensemble, par exemple le formulaire, l'action serveur, la protection anti-spam et le service d'envoi. Le projet possède des tests unitaires, des tests de composants et des parcours de bout en bout, mais les dépendances externes sont souvent simulées. Resend, reCAPTCHA et la limitation de débit sont remplacés par des mocks, c'est-à-dire des versions contrôlées pour les tests. Il manque donc des scénarios dédiés validant plus fidèlement les frontières entre l'application déployée et ses services.
Des tests à écrire plus tôt.
Si je recommençais, je définirais les critères de réussite et les principaux scénarios avant ou pendant les premières fonctions, plutôt qu'après leur accumulation. Tester tôt oblige à clarifier l'interface attendue et rend les régressions plus faciles à attribuer. Les parcours prioritaires seraient la détection de langue, la navigation, le changement de thème, le consentement, le formulaire, les liens circulaires et le rendu responsive.
Un système de consentement artisanal que je ne conserverais probablement pas.
Construire moi-même le bandeau m'a permis de comprendre les catégories, la persistance du choix et le chargement conditionnel des analytics. Pour un usage durable, j'envisage néanmoins une solution existante spécialisée, souvent appelée CMP pour Consent Management Platform. Une CMP maintenue peut fournir une gestion plus complète des fournisseurs, des retraits de consentement et des évolutions réglementaires. Son intégration ne dispense pas de comprendre son comportement ni de vérifier sa configuration.
Une conformité RGPD encore à auditer.
Je ne dois pas affirmer que le portfolio est juridiquement conforme uniquement parce qu'un bandeau de cookies et une politique de confidentialité existent. Le RGPD concerne aussi la nécessité des traitements, l'information fournie, la durée de conservation, les sous-traitants et l'exercice des droits. Le dispositif actuel montre un effort technique réel, mais il doit encore être confronté à un audit et aux recommandations officielles. Cette nuance remplace l'ancienne affirmation trop absolue de « conformité complète ».
Des dictionnaires bilingues longs à maintenir.
Les fichiers français et anglais centralisent correctement les textes d'interface, mais chaque évolution impose de modifier deux ensembles cohérents. Une clé oubliée, une traduction ancienne ou un contenu rédigé différemment peut produire deux profils contradictoires. Les tests détectent certaines absences, pas la qualité sémantique de la traduction. À mesure que le site grandit, il faudra mieux séparer interface courte et contenu éditorial, puis prévoir une méthode de revue des deux langues.
Une assistance IA capable de produire un résultat convaincant mais faux.
L'intelligence artificielle m'a déjà proposé du texte ou du code qui paraissait correct au premier regard mais ne correspondait pas exactement au projet. Je l'ai détecté en consultant le code après la tâche, en comparant la proposition au comportement réel et en exécutant les tests. Un résultat bien formulé n'est donc jamais une validation. La revue humaine reste nécessaire, particulièrement lorsque l'outil décrit une expérience professionnelle ou modifie un mécanisme de sécurité.
Une note actuelle de 7 sur 10.
Le portfolio est complet sur le plan fonctionnel, publié, testé et déjà capable de présenter mon profil. Je retire principalement trois points parce que le design ne me satisfait pas encore et parce que les contenus de compétences et de réalisations sont toujours en cours de consolidation. Cette note traduit un produit utilisable et sérieux, mais pas encore la version professionnelle définitive que je souhaite défendre.
Le header et le footer comme décisions que je referais.
J'ai pensé suffisamment tôt ces deux éléments comme des composants partagés par toutes les pages et par les deux langues. Le header conserve l'identité, la navigation, le thème et le changement de langue ; le footer rassemble la navigation secondaire, les coordonnées et les informations légales. Leur placement dans la mise en page commune évite les duplications et garantit leur présence. Je trouve aujourd'hui leur structure propre et cohérente avec les besoins du portfolio.
Trois premières étapes différentes si je recommençais.
Je commencerais par rédiger et hiérarchiser le contenu selon la grille. Je construirais ensuite les composants réutilisables à partir de ce contenu réel, notamment les cartes et les sections d'articles. Enfin, j'écrirais rapidement les tests des fonctions prioritaires avant de passer au blog, aux animations et aux enrichissements facultatifs. Ce nouvel ordre répond directement aux pertes de temps observées.
Prendre le temps de concevoir avant de développer.
Le principal conseil que je donnerais à un autre développeur est de résister à l'envie de coder immédiatement. Concevoir signifie clarifier le public, les critères, le contenu, l'architecture et l'ordre de livraison. Ce temps peut donner l'impression de retarder le développement, mais il évite ensuite de reconstruire des composants, de déplacer des sections ou d'adapter artificiellement le texte à une interface déjà figée.

Retour au sommaire

Compétences rattachées

Développement Frontend (React/Next.js)Développement Backend & API Amélioration continue Communication DevOps & Administration Serveur

Conception d'un portfolio professionnel

Un projet commencé le 12 mars 2026.

Une réalisation d'abord imposée par ma formation.

Un ancien portfolio devenu insuffisant.

Deux publics principaux : les examinateurs et les recruteurs.

Une vitrine professionnelle sans recherche d'emploi immédiate.

Présenter des capacités plutôt qu'une simple liste de technologies.

Faire apparaître mon objectif de devenir développeur confirmé et référence Odoo.

Montrer un profil plus large grâce aux projets en cours.

Une construction sur mesure pour répondre à la grille.

Une première version beaucoup plus légère.

Un projet élargi par les exigences du diplôme.

Un site destiné à rester vivant après l'évaluation.

Next.js et React choisis pour les performances et l'habitude.

Des outils choisis pour écrire un code propre sans réinventer les bases.

Un design personnel nourri par d'autres portfolios.

Plusieurs journées de travail réparties dans une évolution continue.

Une utilisation transparente de Codex comme outil d'assistance.

Une version française et anglaise pour élargir la lecture.

Des articles MDX conservés dans leur langue de rédaction.

Un blog destiné à partager des solutions difficiles à trouver.

Un domaine public et une identité stable.

Des preuves limitées par la confidentialité de l'entreprise.

Un premier critère de réussite centré sur la clarté du profil.

Viser la totalité des 100 points de la grille.

Préparer une version complète pour août 2026.

Ne laisser aucun critère demandé sans réponse.

Garantir quatre contenus essentiels dès la version évaluée.

Distinguer le périmètre d'évaluation des enrichissements personnels.

Rendre chaque critère facilement vérifiable par les examinateurs.

Prévoir une correspondance plus explicite avec la grille.

Développer les contenus sans rester superficiel.

Conserver une lecture structurée malgré la profondeur.

Atteindre au moins 95 dans chaque catégorie Lighthouse.

Appliquer le même seuil à l'accessibilité.

Ne pas poursuivre artificiellement un classement SEO.

Ajouter un formulaire de contact pour mon usage professionnel.

Comprendre l'utilisation du site grâce aux analytics.

Proposer volontairement une version anglaise.

Publier des preuves professionnelles contrôlées.

Utiliser Codex comme accélérateur de première passe.

Maintenir un portfolio vivant et actualisé.

Un échec principalement causé par un contenu absent ou insuffisant.

Une couverture difficile à contrôler sans correspondance publique.

Un contenu trop superficiel malgré un grand nombre de pages.

L'excès inverse : écrire sans apporter d'information.

Des preuves Odoo censurées pouvant devenir trop vagues.

La publication accidentelle d'une information confidentielle.

Une première passe Codex pouvant déformer l'expérience.

Une authenticité dépendante de la relecture humaine.

Des informations professionnelles susceptibles de devenir obsolètes.

Des animations pouvant nuire au message.

Des traductions française et anglaise pouvant diverger.

Des scores Lighthouse sensibles aux conditions.

Des messages de contact pouvant ne jamais être délivrés.

Le spam pouvant épuiser les quotas d'envoi ou dégrader le service.

Un risque de non-conformité au RGPD avec les analytics.

Un périmètre enrichi mais encore gérable.

Une dette de structure identifiée puis traitée.

Une dépendance remplaçable envers les services externes.

Une date d'août encore incertaine.

Un objectif de 100 % exigeant une vérification du rendu réel.

Cadrer le contenu avant de multiplier les pages.

Installer le bilinguisme avant de construire les pages.

Détecter la langue dès l'arrivée sur le site.

Séparer le chargement serveur et l'usage interactif des traductions.

Poser une architecture Next.js typée et réutilisable.

Explorer l'identité visuelle dans Figma.

Construire un système visuel commun à partir d'une bibliothèque de composants.

Développer les contenus principaux dans un ordre progressif.

Rendre l'identité et la navigation persistantes.

Modéliser dix compétences comparables.

Donner à chaque compétence une structure éditoriale identique.

Structurer les cinq réalisations comme des études de cas.

Garantir la navigation circulaire par les données et les tests.

Transformer le parcours en frise anti-chronologique.

Ajouter des animations discrètes dès la première version.

Unifier le défilement et les transitions entre pages.

Préserver le responsive et les préférences d'affichage.

Créer un blog technique avec MDX.