Vibe coding freelance : premiers clients sans portfolio

Le terme peut attirer l'attention, mais un dirigeant n'achète pas du vibe coding freelance. Il achète moins de saisies manuelles, un parcours de prise de rendez-vous moins fragile, une page qui explique mieux une offre, ou un petit outil qui évite une tâche répétitive. Commencez donc par traduire votre capacité de production en situation métier observable. Évitez « je crée des apps avec l'IA » ; préférez « j'aide les cabinets de recrutement à transformer un brief récurrent en page de mission prête à relire » ou « j'aide les artisans multi-sites à centraliser les demandes provenant de leurs formulaires ».

Cette précision vous donne quatre éléments à écrire avant toute prospection :

• un segment limité : un métier, une taille d'entreprise, un territoire ou un modèle opérationnel ;
• un déclencheur visible : formulaire pauvre, données dupliquées, devis traité par e-mail, information difficile à trouver ;
• un résultat de première étape : audit court, maquette cliquable, automatisation contrôlée ou écran pilote ;
• une limite explicite : ce qui n'est pas inclus et ce qui devra être validé par le client.

Un bon angle ne prétend pas que tous les acteurs d'un secteur ont le même problème. Il décrit une hypothèse que vous pourrez confirmer. Par exemple, une entreprise qui reçoit des demandes depuis un formulaire généraliste n'a pas forcément besoin d'un nouveau CRM ; elle peut avoir besoin d'une meilleure qualification en amont. Cette distinction évite de vendre un produit avant d'avoir compris le flux réel. Pour structurer cette étape, partez d'une grille de qualification avant l'outbound : compatibilité avec votre offre, signal public, puis action suivante.

Le portfolio n'est pas le point de départ de la confiance. La clarté l'est. Si vous pouvez expliquer à qui s'adresse votre intervention, quelle friction vous regardez et quelle décision le client pourra prendre après la première étape, vous êtes déjà plus crédible qu'une présentation remplie de captures sans contexte.

Sans historique public, la mission la plus difficile à vendre est la transformation totale : refonte complète, plateforme sur mesure ou « assistant IA » sans périmètre. Le client devrait vous croire sur le résultat, le budget, le calendrier et la qualité avant même d'avoir travaillé avec vous. Réduisez cette charge avec une micro-offre d'entrée. Elle doit avoir un début, une fin, un livrable lisible et une décision de sortie.

Une micro-offre pertinente ne consiste pas à travailler gratuitement jusqu'à convaincre. Elle crée une étape achetable : cartographier un flux de demande, produire un prototype sur données fictives, remettre une recommandation priorisée, ou intégrer un seul formulaire à un espace de suivi. Le prix peut être fixe ou encadré par une fourchette, mais le plus important est le critère d'acceptation. Exemple : « à la fin, vous aurez un écran testable qui transforme les trois champs actuels en brief structuré ; nous déciderons ensemble s'il mérite une intégration ».

Voici un test simple. Votre offre d'entrée répond-elle à ces cinq questions sans jargon ?

1. Pour quel type d'entreprise est-elle conçue ?
2. Quel travail pénible ou incertain cherche-t-elle à réduire ?
3. Qu'est-ce qui sera visible à la fin ?
4. Quelles données, accès ou validations restent chez le client ?
5. Que se passe-t-il si le pilote ne justifie pas une suite ?

Cette dernière question rassure. Vous ne vendez pas une dépendance à une solution opaque ; vous proposez une expérience de décision. Le vibe coding est alors un moyen d'itérer vite, pas un raccourci qui masque la qualité. Documentez aussi vos garde-fous : revue humaine des données, environnements séparés, absence de mise en production sans accord, et retour possible à un processus manuel.

Une micro-offre se vend mieux lorsqu'elle limite un risque précis. Elle ne promet pas de « digitaliser l'entreprise » ; elle aide un décideur à savoir, avec un coût maîtrisé, si une amélioration mérite un projet.

Un portfolio ne doit jamais être remplacé par de faux logos, de faux avis ou des études de cas imaginées. En revanche, vous pouvez montrer votre méthode avant d'avoir signé. Le bon réflexe est de créer des preuves de raisonnement, clairement étiquetées comme démonstrations, sur des situations fictives ou publiques non confidentielles. Leur rôle n'est pas de faire croire que vous avez déjà livré ; il est de montrer comment vous observez, cadrez et vérifiez.

Préparez quatre formats complémentaires. D'abord, une fiche d'une page décrivant un problème et les questions à poser avant de développer. Ensuite, une courte vidéo d'écran, sans promesse excessive, où vous montrez un prototype et ses limites. Ajoutez un exemple de spécification : données d'entrée, règle métier, sortie attendue, cas d'erreur. Enfin, rédigez une note « ce que je ne ferais pas sans validation » : données sensibles, envoi automatique, publication ou connexion à un outil tiers.

Le prototype doit être utile à la conversation, pas spectaculaire à tout prix. Une simulation d'un formulaire qui route des demandes, un tableau de priorisation ou un générateur de brief peut suffire. Dans chaque démonstration, séparez visuellement ce qui est réel, ce qui est fictif et ce qui reste à confirmer. Cette transparence est particulièrement importante lorsque l'IA intervient dans la production du code : un client compétent comprendra qu'une démo n'est pas encore un système exploitable ; un client moins technique appréciera que vous ne brouilliez pas la frontière.

Conservez ces preuves dans une page simple. Pour chacune, indiquez le contexte, l'hypothèse, le périmètre, la durée de réalisation et les limites. Ne dites jamais « cas client » lorsqu'il s'agit d'une démonstration. Ce niveau de précision devient un avantage commercial : le prospect voit que vous savez distinguer une idée, un pilote et une livraison maintenable.

Quand on débute, la tentation est de contacter n'importe quelle entreprise susceptible d'avoir besoin de numérique. C'est coûteux : votre message devient vague, votre recherche s'allonge et les réponses ne vous apprennent rien. Construisez plutôt une petite liste de comptes où votre hypothèse peut être vérifiée depuis des sources publiques. L'objectif n'est pas de déduire un besoin intime ni de collecter des données personnelles inutiles ; il est de repérer un contexte qui rend une question légitime.

Pour une micro-offre liée aux demandes entrantes, cherchez par exemple des entreprises qui affichent un formulaire très minimal, plusieurs canaux de contact concurrents ou une promesse qui suppose une qualification humaine lourde. Pour une offre liée aux devis, observez les pages « demander un devis », la diversité des prestations et la présence de documents téléchargeables. Pour un outil interne, ciblez d'abord les métiers où une même information réapparaît dans plusieurs étapes publiques : réservation, candidature, demande de disponibilité ou suivi de dossier.

Créez ensuite une fiche par compte avec seulement cinq champs : activité, élément observé, hypothèse prudente, interlocuteur ou rôle probable, prochaine action. Ajoutez une date et l'URL de la source. Si vous ne pouvez pas justifier votre hypothèse en une phrase, ne contactez pas encore. Cette discipline rejoint la méthode pour trouver des prospects grâce à l'IA : un outil peut accélérer la recherche, mais il ne doit pas transformer une supposition en certitude.

Limitez volontairement la première liste. Vingt comptes bien documentés valent davantage que deux cents noms copiés dans un tableur. Vous aurez le temps de relire les observations, d'éviter les doublons et de préparer une approche adaptée. Un outil tel que SprintLead pour les agences peut aider à organiser les signaux et le suivi ; il ne dispense jamais de contrôler la pertinence de chaque compte.

Votre premier message n'a pas à démontrer toute votre expertise. Il doit mériter une réponse. Une structure courte fonctionne mieux qu'une séquence grandiloquente : observation factuelle, hypothèse modeste, question simple, sortie facile. Ne prétendez pas avoir « analysé en profondeur » une entreprise après cinq minutes sur son site. Ne mentionnez pas des détails personnels. Et ne cachez pas l'intention commerciale derrière une fausse conversation.

Un exemple pour une offre de qualification de demandes : « Bonjour, j'ai vu que vos demandes de devis passent par un formulaire très court, alors que vous proposez plusieurs types d'intervention. Je me demande si votre équipe doit reprendre beaucoup d'informations avant de pouvoir orienter une demande. Je travaille sur de petits pilotes pour structurer ce brief sans changer tout le système. Est-ce un sujet que vous regardez cette année ? Si ce n'est pas prioritaire, je n'insiste pas. »

Ce message ne suppose pas que le problème existe ; il ouvre une vérification. Adaptez l'observation à chaque compte et gardez le même niveau de prudence. Votre appel à l'action peut être une réponse binaire, un échange de quinze minutes ou l'autorisation d'envoyer une maquette contextualisée. Il ne doit pas imposer une démonstration ni un calendrier.

Préparez aussi vos réponses aux objections prévisibles. « Nous avons déjà un outil » peut mener à une question sur le flux non couvert. « Nous n'avons pas le budget » peut justifier une ressource utile ou une fermeture polie, pas une réduction improvisée. « Envoyez des exemples » est l'occasion d'envoyer vos démonstrations en précisant leur nature. La qualité du suivi compte autant que l'accroche. Notez le statut et la raison de chaque réponse dans un CRM, puis n'envoyez pas de relance automatique si le contact a clairement décliné.

La première mission est moins un trophée qu'un système à documenter. Dès le cadrage, demandez ce que vous pourrez montrer une fois le travail terminé. Certains clients accepteront une formulation anonymisée, une capture floutée, un avant/après sur le processus ou un témoignage validé. D'autres ne le souhaiteront pas. Dans ce cas, respectez le refus et valorisez ce que vous avez appris sans révéler le contexte : une méthode, une checklist, une amélioration générique.

À la fin d'un pilote, organisez une revue en cinq points : problème initial, hypothèse, livrable, ce qui a été mesuré ou observé, suite décidée. Ne transformez pas automatiquement un retour positif oral en citation publique. Proposez une validation écrite avec le texte exact, le nom à utiliser et les limites de diffusion. Cette rigueur protège la relation et vous évite de bâtir une crédibilité fragile.

Votre nouveau portfolio doit raconter des décisions, pas seulement montrer des écrans. Pour chaque intervention, expliquez la contrainte, le périmètre, votre rôle, les validations et ce qui restait hors projet. Ajoutez éventuellement une courte section technique, mais uniquement si elle éclaire la maintenance, la sécurité ou l'exploitation. Un prospect sérieux cherchera surtout à savoir comment vous travaillez quand l'ambiguïté apparaît.

Enfin, mettez à jour votre offre à partir des signaux réels. Si les premiers échanges confirment un même blocage, affinez la micro-offre. S'ils révèlent des besoins trop variés, resserrez le segment plutôt que d'élargir votre promesse. Le prix et le périmètre deviendront plus faciles à défendre parce qu'ils reposent sur des conversations réelles. Le portfolio arrive après la méthode ; il ne doit pas servir à cacher l'absence de méthode.

Le prix est souvent le point qui fait basculer un premier échange, non parce qu'un prospect cherche forcément le moins cher, mais parce qu'il ne sait pas encore comment comparer votre proposition. Le vibe coding freelance peut créer une attente dangereuse : si l'IA accélère une partie de la production, pourquoi ne pas demander un résultat immédiat et presque gratuit ? Répondez sans défendre votre temps de clavier. Le prix couvre le diagnostic, le cadrage, les choix, les tests, les corrections et la responsabilité de dire qu'une demande doit être revue. La vitesse de prototypage peut réduire une partie du coût d'exploration ; elle ne supprime pas le travail qui rend un résultat utilisable.

Présentez un pilote avec trois dimensions séparées : le périmètre fonctionnel, le délai de travail et les conditions de remise. Un périmètre peut se limiter à un formulaire et à une vue de suivi ; un délai peut prévoir un atelier, une première version, un retour et une correction ; la remise peut inclure le dépôt de code, les instructions de reprise et la liste des dépendances. Cette formulation évite le malentendu « livré » contre « prêt à exploiter ». Si une intégration, une sécurité renforcée, une reprise de données ou une formation est nécessaire, elle doit devenir une décision suivante, chiffrée séparément.

Donnez aussi une règle claire pour les changements. Pendant le pilote, une correction qui rapproche le livrable du critère d'acceptation est normale. Une nouvelle fonctionnalité, une nouvelle source de données ou un nouveau public ne l'est pas automatiquement. Notez ces demandes dans une liste de suite et expliquez leur impact avant de les accepter. Cette conversation n'est pas bureaucratique : elle protège la capacité du client à décider et la vôtre à livrer.

Ajoutez un rituel de remise très simple. Avant la dernière réunion, envoyez au client une liste des scénarios testés, des accès dont il devient propriétaire, des points qui restent ouverts et de la prochaine personne à prévenir en cas de problème. Pendant la démonstration, laissez la personne utiliser le résultat au lieu de cliquer à sa place. Demandez ensuite : « quelle action souhaitez-vous réaliser dès demain ? » et « quel point vous empêcherait de le faire ? ». Ces deux questions révèlent souvent une étape oubliée : une règle métier non écrite, un droit d'accès, une personne à former ou un cas d'exception. Les traiter avant de déclarer le pilote terminé est plus utile qu'ajouter une fonction décorative.

Préparez enfin une proposition de suite qui n'est pas automatique. Elle peut être l'arrêt du projet, une période d'observation, une correction ciblée ou une phase d'intégration. Expliquez l'effort, le propriétaire côté client et le risque réduit par chaque option. Cette manière de conclure un pilote fait du vibe coding freelance une pratique professionnelle : vous livrez une base explicable, vous n'enfermez pas le client dans un outil, et vous laissez la décision commerciale à ceux qui assument le besoin.

Enfin, ne cachez pas votre manière de travailler, mais ne laissez pas l'outil devenir la promesse. Vous pouvez dire que vous utilisez des assistants de code pour explorer et accélérer certaines tâches, puis préciser que le client valide le besoin et que vous contrôlez le résultat. Un décideur raisonnable cherche de la transparence : qui est responsable, comment les données sont traitées, quels tests ont été faits et comment le travail pourra être maintenu. Une réponse concise à ces questions renforce davantage la confiance qu'un discours sur la magie de l'IA.