Décrocher une mission via un grant de fondation Web3 : la checklist juridique du freelance

Vous venez de recevoir un message : la fondation derrière un écosystème Solana, Polkadot ou NEAR vous propose un grant pour développer un oracle, un module de staking ou un outil d'infrastructure open source. La somme est attractive, le prestige aussi. Mais avant d'ouvrir votre éditeur, comprenez ce que vous signez vraiment.

Un grant n'est juridiquement pas une commande classique. C'est souvent une subvention conditionnelle à la livraison de jalons (milestones), parfois assortie d'une obligation de publier le code en open source. La contrepartie n'est pas un prix ferme mais un déblocage progressif de fonds. Et surtout, le donneur d'ordre peut être une fondation à l'étranger, une entité ad hoc, voire une organisation décentralisée sans personnalité juridique claire.

Cette nature hybride change tout : vos recours en cas de non-paiement, votre responsabilité en cas de bug, et même votre régime fiscal. Aborder un grant comme une simple facturation freelance est la première erreur.

La question la plus importante n'est pas technique, elle est juridique : avec qui contractez-vous ? Trois cas de figure, trois niveaux de sécurité :

• Une fondation immatriculée (Suisse, Singapour, Cayman…) : une personne morale identifiable, avec qui vous pouvez signer un vrai contrat et que vous pouvez attaquer en cas de litige. C'est le scénario le plus protecteur.
• Une société d'exploitation (labs) qui contracte pour le compte de l'écosystème : également une entité saisissable, sous réserve de vérifier sa solvabilité.
• Une DAO sans personnalité juridique : un collectif d'adresses qui vote des paiements. En cas de conflit, vous n'avez personne à assigner et aucune juridiction naturelle. C'est le scénario le plus risqué.

Avant toute ligne de code, exigez de savoir quelle entité signe, dans quel pays elle est immatriculée et qui l'engage. Un grant sérieux passe toujours par un document contractuel — sa simple existence est un bon signal de sécurité.

Beaucoup de grants Web3 versent tout ou partie de la rémunération en jetons natifs de l'écosystème plutôt qu'en euros. Cette modalité, banale dans le secteur, ouvre trois expositions que vous ne rencontrez jamais sur une mission facturée en monnaie classique :

1. Le risque de change : un token valant 5 000 € à la signature peut en valoir 2 000 € à la livraison du dernier jalon. Votre rémunération réelle est volatile.
2. Le risque de liquidité : certains tokens sont soumis à une période de blocage (vesting) ou difficiles à convertir sans faire chuter le cours.
3. L'exposition fiscale : en France, recevoir des tokens en contrepartie d'une prestation constitue un revenu professionnel imposable, évalué en euros au jour de la réception. Vous devez le déclarer, indépendamment de la revente ultérieure.

Réflexe à adopter : convertir mentalement chaque paiement en euros à la date de réception, tracer ces valeurs pour votre comptabilité, et négocier si possible une part en stablecoin ou en euros pour couvrir vos charges et impôts.

Imaginez un désaccord sur un jalon : la fondation estime la livraison non conforme et bloque le paiement. Où réglez-vous ce conflit ? Avec une fondation à Singapour et un développeur en France, la réponse n'a rien d'évident.

Les contrats de grant prévoient généralement une clause de droit applicable et une clause de règlement des différends. Lisez-les attentivement : un arbitrage international à l'étranger peut vous coûter plus cher que l'enjeu du litige lui-même. Privilégiez, quand vous pouvez négocier, un droit et une langue que vous maîtrisez, ou à défaut un mode de résolution proportionné.

C'est ici que la protection juridique prend tout son sens. Incluse dans une RC Pro bien construite, elle prend en charge l'analyse de vos contrats, le conseil en cas de différend et les frais de procédure — y compris lorsque le litige se déroule à l'international. Pour un freelance isolé face à une fondation rompue aux montages juridiques, c'est un rééquilibrage décisif.

Un piège fréquent : croire que livrer du code open source dans le cadre d'un grant vous exonère de toute responsabilité. C'est faux. La licence open source encadre l'usage du code par des tiers, mais elle ne régit pas votre relation contractuelle avec la fondation qui vous a payé.

Si le module que vous livrez contient une faille exploitée après son intégration dans un protocole, la fondation ou un projet dérivé peut vous reprocher la qualité de votre travail. Le caractère public et irréversible du déploiement on-chain rend, là encore, toute faille technique parfaitement traçable.

Trois protections concrètes :

• Une RC Pro couvrant les missions en France et à l'international, car votre donneur d'ordre est presque toujours étranger.
• Une couverture des frais de défense dimensionnée pour des procédures potentiellement collectives (class action d'utilisateurs).
• Le réflexe de traiter séparément le risque sur votre environnement de travail : un dépôt privé exposé ou un poste compromis avant la publication relève de l'assurance cyber, pas de la RC Pro.

Pour transformer une opportunité de grant en mission sécurisée, déroulez systématiquement cette liste :

Les programmes de grants les plus structurés exigent d'ailleurs une attestation d'assurance avant de débloquer les fonds. Présenter une RC Pro à jour n'est donc pas seulement une protection : c'est souvent la clé qui débloque la mission elle-même.