Un dépôt Git peut montrer que vous savez écrire du code. Il explique moins bien à un dirigeant pourquoi il devrait vous confier sa migration, sa maintenance ou son automatisation. Votre site sert à faire le lien : présenter le problème que vous résolvez, montrer votre méthode et permettre un premier contact sans obliger le visiteur à déchiffrer votre environnement technique.
Pour un freelance Linux, le meilleur site n’est pas forcément le plus sophistiqué : c’est celui que vous pouvez maintenir et dont un client comprend l’offre. Un site statique peut suffire. WordPress peut être plus confortable si vous publiez souvent ou partagez la rédaction. Le choix dépend davantage de votre organisation que d’une préférence de principe.
Commencer par cinq questions de client
Avant de choisir un générateur ou un hébergeur, écrivez les réponses que votre site doit fournir. Que prenez-vous en charge ? Pour qui ? Avec quelles limites ? Sur quelles preuves peut-on s’appuyer ? Comment démarre une mission ? Si ces réponses manquent, une architecture élégante ne compensera pas le flou.
« Administration Linux, DevOps, cloud et cybersécurité » couvre beaucoup de choses. « Maintenance de serveurs Linux pour petites équipes sans administrateur à temps plein » décrit un besoin plus identifiable. Vous pouvez avoir plusieurs offres, mais chacune mérite un périmètre compréhensible : audit, intervention ponctuelle, accompagnement ou suivi récurrent.
Soyez explicite sur les contraintes. Travaillez-vous à distance ? Acceptez-vous les urgences ? Assurez-vous une astreinte ou seulement des interventions planifiées ? Une phrase honnête sur vos disponibilités évite des demandes impossibles à satisfaire et rassure davantage qu’un vague « disponible à tout moment ».
Choisir une solution que vous aurez envie d’entretenir
| Approche | Elle convient si… | Point à anticiper |
|---|---|---|
| Site statique avec générateur | Vous êtes à l’aise avec les fichiers et publiez seul | Chaîne de construction, formulaires et mises à jour des dépendances |
| WordPress | Vous voulez une rédaction visuelle et des fonctions éditoriales | Maintenance, sauvegardes et sélection raisonnable des extensions |
| Développement sur mesure | Votre site nécessite une fonction métier réellement spécifique | Temps de réalisation, documentation et coût d’entretien |
Hugo et Jekyll sont des exemples connus de générateurs statiques, mais leur nom ne doit pas devenir un critère commercial. Votre client n’achète pas la manière dont votre page « Contact » a été compilée. Choisissez surtout un outil que vous comprenez assez pour corriger une panne et refaire un déploiement six mois plus tard.
Le statique réduit certains besoins côté serveur, sans supprimer toute maintenance. Il reste le nom de domaine, le certificat, les dépendances, les services tiers et les accès de déploiement. À l’inverse, WordPress n’oblige pas à installer une extension pour chaque détail visuel. Un petit périmètre bien tenu est souvent plus durable qu’un empilement de fonctionnalités.
Un cas client vaut mieux qu’une longue liste de technologies
Construisez chaque étude de cas autour de quatre éléments : la situation de départ, les contraintes, votre intervention et le résultat vérifiable. Si vous n’avez pas le droit de nommer le client, anonymisez le contexte sans inventer une entreprise. Faites valider ce qui peut être publié, surtout les captures et les chiffres.
Voici un canevas fictif, à compléter uniquement avec des faits issus d’une vraie mission :
Situation : une petite équipe réalise manuellement une opération récurrente. Contrainte : le service doit rester disponible pendant l’intervention. Travail : documentation du processus, automatisation et procédure de retour arrière. Résultat : temps mesuré avant et après, avec période d’observation et limites.
Ne publiez pas seulement un pourcentage spectaculaire. Une baisse de temps n’a de sens que si l’on connaît la tâche, la mesure et les éventuelles différences de périmètre. Une mission sans chiffre peut rester convaincante si vous expliquez une décision difficile : pourquoi une migration a été reportée, comment une dépendance a été isolée ou ce qui a été volontairement laissé hors du projet.
Montrer du code sans livrer les clés du client
Un extrait court et commenté peut illustrer votre raisonnement. Nettoyez les noms internes, adresses IP, secrets, chemins sensibles et données personnelles. Relisez aussi l’historique d’un dépôt avant de le rendre public : retirer un secret du dernier fichier ne le supprime pas forcément des anciens commits.
Pour des exemples publiables, un petit projet de démonstration est souvent plus simple qu’un dépôt de production lourdement anonymisé. Indiquez qu’il s’agit d’une démonstration. Le lecteur doit pouvoir distinguer ce qui a été réellement déployé et ce qui sert uniquement à expliquer une approche.
Prévoir le contact et la suite de la demande
Un formulaire utile demande peu d’informations : le besoin, l’échéance, le contexte technique général et un moyen de réponse. Il ne doit pas inviter un prospect à envoyer ses mots de passe ou une sauvegarde complète. Si une analyse détaillée nécessite un accès, organisez-la ensuite dans un cadre adapté.
Testez le formulaire après la mise en ligne et après une modification importante. Vérifiez l’arrivée du message, la confirmation affichée et la lisibilité sur téléphone. Précisez un délai de réponse réaliste plutôt qu’une promesse instantanée. Une adresse de contact visible peut servir de solution de secours lorsque le formulaire pose problème.
Faut-il publier vos tarifs ? Un prix de départ peut filtrer les demandes, à condition d’expliquer ce qu’il comprend. Un tarif journalier sans contexte ne dit pas combien coûtera le projet. Pour une intervention variable, donnez plutôt les informations nécessaires au devis et la manière dont vous délimitez le travail.
Le référencement commence par votre spécialité
Écrivez des pages sur les problèmes que vous souhaitez réellement traiter. Une procédure générique copiée partout apporte peu à un prospect. Un article expliquant comment préparer un audit, ce qu’un client doit sauvegarder ou pourquoi une intervention demande une fenêtre de maintenance peut être plus utile.
Reliez ces contenus aux services correspondants, sans transformer chaque paragraphe en argumentaire. Si votre site n’apparaît pas, utilisez le diagnostic d’indexation et de visibilité avant de multiplier les pages. Si la technique fonctionne mais que les demandes restent vagues, revoyez d’abord le positionnement de l’offre.
Vous pouvez aussi confier la réalisation à un prestataire tout en gardant la main sur votre contenu. Une agence web Plaisance-du-Touch constitue une piste locale pour ce type de projet ; demandez surtout la propriété du domaine, la remise des accès, les modalités de maintenance et la possibilité de récupérer le site. Notre article sur Webinfun et le cadrage d’un site professionnel propose les points à préciser dans le brief.
La vérification avant de partager votre adresse
Parcourez le site comme un prospect pressé : une offre claire, un exemple crédible, un contact qui fonctionne. Vérifiez les liens, les images, les pages d’information et les sauvegardes. Essayez une restauration sur un environnement séparé lorsque votre organisation le permet ; posséder une archive ne prouve pas qu’elle est exploitable.
Réservez enfin un petit créneau d’entretien régulier. Retirez une compétence que vous ne proposez plus, actualisez vos disponibilités et corrigez les exemples devenus obsolètes. Un site sobre et vivant rend davantage service qu’un portfolio ambitieux abandonné dès la première mission.
À lire aussi
Créer un site sans coder : choisir un outil no code et publier proprement
Community manager en alternance ou freelance : quel départ choisir ?
Comment copier un site web complet : archive ou vraie sauvegarde ?
Webinfun : préparer la création ou la refonte de votre site professionnel
Site invisible sur Google : diagnostiquer la cause avant de tout refaire
Quand donner son numéro WhatsApp sur un site de rencontre ?
