Freelance .NET : comment trouver
des missions ESN de qualité
et éviter les pièges

Quand j'ai franchi le pas du freelance, j'avais une idée assez naïve du marché : les missions se trouveraient facilement, les ESN seraient honnêtes sur les projets, et un bon profil technique suffirait. La réalité est plus nuancée. Le marché du freelance .NET est réel et porteur, mais il demande une approche aussi stratégique que n'importe quel projet d'architecture. Voici ce que j'aurais aimé savoir dès le départ.

Où trouver des missions : les canaux classés par efficacité réelle

Je vais être direct : tous les canaux ne se valent pas, et la plupart des freelances débutants investissent leur énergie là où le retour est le plus faible.

La cooptation : le canal roi, trop souvent négligé

Les meilleures missions que j'ai eues ne venaient pas d'une plateforme. Elles venaient d'un DSI que j'avais croisé trois ans plus tôt sur un projet, ou d'un chef de projet qui m'avait vu travailler et m'a recommandé à son réseau quand il a changé d'entreprise. La cooptation génère des missions sans compétition, avec un niveau de confiance déjà établi, et souvent à de meilleures conditions que le marché.

Le problème : ça ne se construit pas en claquant des doigts. Chaque mission bien livrée est un investissement dans votre réseau futur. Je prends soin de rester en contact avec les personnes avec qui j'ai travaillé — pas de façon artificielle, mais en partageant ce qui m'a été utile, en commentant leurs publications, en les recontactant quand j'ai quelque chose de pertinent à partager.

LinkedIn : utile si vous l'utilisez autrement que tout le monde

LinkedIn génère des sollicitations — surtout de la part de business developers ESN qui font du volume. Pour en tirer de la valeur, il faut inverser la logique : ne pas attendre d'être trouvé, mais créer des raisons d'être trouvé. Je publie régulièrement sur des sujets .NET précis — architecture, DDD, TDD, Clean Architecture. Ces publications attirent des CTO, des DSI et des lead devs qui cherchent exactement ce type de profil, pas un "développeur .NET" générique.

Un profil LinkedIn optimisé pour le freelance .NET, c'est aussi un titre précis (Lead Developer .NET — Clean Architecture, DDD, .NET 9), une section "À propos" qui répond à "pourquoi vous plutôt qu'un autre", et des recommandations vérifiables de clients ou de chefs de projet passés.

Malt et les plateformes : utiles, mais pas pour les meilleures missions

Malt et les plateformes similaires ont un rôle dans le mix — elles exposent à des clients directs qui ne passent pas par les ESN. Mais elles sont aussi très compétitives sur les prix, et les missions proposées sont souvent moins techniquement intéressantes que celles issues du réseau. Je m'y maintiens comme signal de présence, pas comme source principale de missions.

Le contact direct avec les ESN partenaires

Certaines ESN ont des partenariats récurrents avec des grands comptes et cherchent des freelances fiables pour compléter leurs équipes. La différence entre une ESN partenaire de qualité et un agrégateur de CV, c'est la connaissance réelle des projets chez leurs clients. Une bonne ESN sait vous décrire les projets en cours avec précision — les technos, le niveau de dette technique, la maturité Agile de l'équipe. Si le commercial ne peut pas répondre à ces questions, passez.

"Le marché du freelance technique ne manque pas de demande. Il manque de profils spécialisés en qui les clients ont confiance. C'est sur cette confiance qu'il faut investir, pas sur la visibilité brute."

Évaluer une mission avant d'accepter

La plus grande erreur que j'ai faite en début de freelance : accepter des missions sans les questionner, parce que j'avais besoin de remplir mon carnet de commandes. Une mauvaise mission coûte bien plus qu'un mois de chiffre d'affaires manqué — elle immobilise six mois pendant lesquels vous ne progressez pas, votre réseau stagne, et vous portez le poids d'un contexte technique délétère.

Les questions à poser systématiquement

Avant d'accepter n'importe quelle mission, je pose ces questions — et je juge autant les réponses que la façon dont elles sont données :

• Pourquoi ce besoin maintenant ? Une mission qui s'ouvre en urgence après le départ d'un développeur précédent mérite d'en comprendre les raisons.
• Comment sont gérés les déploiements en production ? La réponse révèle immédiatement la maturité DevOps de l'équipe. "On déploie le vendredi soir" est un signal fort.
• Quelle est la couverture de tests sur les parties critiques ? Si la réponse est évasive ou si le sujet semble inconnu, vous savez à quoi vous attendre.
• Quel est le turnover technique sur ce projet ces 12-18 mois ? La transparence — ou l'absence de réponse — est en soi une information.
• Comment les décisions techniques sont-elles prises ? Un projet où le lead technique freelance n'a aucune latitude ne vous permettra pas de délivrer ni d'apprendre.

Négocier son TJM sans s'excuser

La négociation du TJM est l'endroit où beaucoup de freelances laissent de l'argent sur la table — souvent par inconfort avec la discussion commerciale. Quelques principes qui m'ont aidé.

Connaître sa valeur marché réelle

Le TJM n'est pas ce que vous "osez" demander — c'est la valeur que vous créez rapportée aux contraintes du marché. Un Lead Dev .NET qui évite un bug critique, qui accélère l'onboarding d'une équipe, qui réduit de moitié le temps de debugging en production crée une valeur bien supérieure à son TJM journalier. Ancrez la négociation dans cette valeur, pas dans des comparaisons avec "ce que font les autres".

Ne pas négocier contre soi-même

La règle la plus simple : annoncez votre TJM, puis taisez-vous. Le silence inconfortable après une annonce pousse beaucoup de freelances à se justifier, à proposer des compromis, à céder avant même que l'interlocuteur ait réagi. Laissez l'autre répondre en premier. Souvent, la réponse est un simple "OK" — vous auriez cédé pour rien.

La spécialisation comme levier de TJM

Le levier le plus puissant sur le TJM n'est pas l'expérience en années — c'est la précision de la spécialisation. "Développeur .NET" est interchangeable. "Lead Dev .NET spécialisé Clean Architecture et systèmes distribués sur Azure" est rare. Plus votre profil est précis et cohérent, moins il y a de comparants directs et moins la négociation porte sur le prix.

"Un généraliste se bat sur le prix. Un spécialiste se bat sur la disponibilité. Je préfère que les missions attendent que je sois libre plutôt que de devoir en accepter une à n'importe quel tarif."

Les red flags à ne jamais ignorer

L'expérience m'a appris à reconnaître certains signaux d'alarme que j'aurais dû fuir plus tôt et plus vite.

• Le brief change plusieurs fois avant la signature : si le périmètre de mission n'est pas stabilisé avant le contrat, il ne le sera pas pendant la mission.
• L'ESN ne peut pas vous mettre en contact avec le client final avant la signature : dans les missions sérieuses, le freelance rencontre l'équipe technique avant d'accepter. Refuser cet échange cache souvent quelque chose.
• Le TJM proposé est nettement sous le marché avec une promesse de "montée en charge rapide" : cette promesse ne se matérialise que rarement, et vous êtes parti de bas.
• La mission est décrite comme "simple" et "bien documentée" : dans mon expérience, les missions décrites ainsi cachent systématiquement une dette technique importante ou une organisation dysfonctionnelle.
• On vous demande de signer vite parce que "d'autres freelances sont intéressés" : la pression de décision artificielle est une technique de vente, pas un signe de qualité.

Construire une relation durable avec les ESN

Le marché ESN fonctionne sur la confiance et la répétition. Une ESN qui vous a vu bien travailler sur une mission est votre meilleur commercial pour la suivante. Quelques pratiques concrètes que j'ai mises en place.

Je maintiens une relation régulière avec les commerciaux et managers de compte avec qui j'ai eu de bonnes expériences — pas pour quémander des missions, mais pour rester dans leur radar. Je les tiens informés de mes disponibilités à venir avec 4 à 6 semaines d'avance. Je partage les retours positifs que j'ai eus de leurs clients — ça les aide à vendre les prochaines missions.

Je suis aussi honnête quand une mission ne me convient pas. Dire "ce projet ne correspond pas à mon profil, mais voilà ce que je pourrais apporter sur ce type de mission" est bien plus valorisant que d'accepter une mission mal adaptée et de la mal exécuter. Les ESN de qualité apprécient la clarté — elle leur évite des problèmes avec leurs clients.

Le remote comme différenciateur, pas comme avantage acquis

Le travail à distance est devenu une norme dans le monde du freelance .NET depuis 2020. Mais c'est un avantage qui se mérite et se maintient — pas un droit acquis. Les freelances qui travaillent le mieux en remote sont ceux qui communiquent de façon plus proactive qu'en présentiel : mises à jour régulières, documentation des décisions, présence visible dans les rituels d'équipe.

Ma position géographique à La Rochelle n'a jamais été un obstacle pour travailler avec des clients à Paris, Lyon ou Bordeaux. Ce qui compte, c'est la qualité de la communication asynchrone, la réactivité, et la démonstration régulière de la valeur produite. Le remote compresse les écarts géographiques — mais il amplifie aussi les écarts de professionnalisme.

Pour un freelance .NET qui veut construire une carrière solide sur le long terme, la spécialisation et la réputation sont les deux actifs les plus importants. Le reste — les plateformes, les ESN, les canaux de sourcing — sont des outils au service de ces deux fondamentaux. Investissez en conséquence.