[!NOTE] TL;DR : La livraison asynchrone freelance IA repose sur des preuves de recette que le client peut vérifier sans réunion. Dans un dépôt que j'ai documenté, 3 fichiers de tests sur 5 étaient vides : une démo n'aurait pas révélé ce trou. Je distingue ci-dessous les constats du dépôt, les tarifs publiés par Malt et mes simulations de capacité, sans confondre chiffre d'affaires projeté et encaissé.
Le dépôt au moment de la remise
J'ai trouvé trois fichiers de tests vides. Ma confiance, elle, compilait très bien. C'est en relisant la documentation technique d'une application de collecte sur le terrain que j'ai rencontré ce décalage. Le cas n'est pas un mandat commercial d'agent IA : c'est un dépôt professionnel qui expose exactement le problème de preuve que je retrouve dans la livraison asynchrone freelance IA.
Sur cinq emplacements de tests décrits, deux contenaient des cas de test et trois étaient vides. Je ne transforme pas ce décompte en taux de couverture. Les fichiers renseignés concernent notamment la participation et des vues web ; rien, dans cette seule documentation, ne prouve une exécution complète en CI.
{
"type": "bar",
"data": {
"labels": ["Fichiers avec cas de test", "Fichiers de tests vides"],
"datasets": [{"label": "Inventaire documentaire du dépôt", "data": [2, 3], "backgroundColor": ["#3b82f6", "#ef4444"]}]
},
"options": {
"responsive": true,
"plugins": {"title": {"display": true, "text": "Cinq emplacements de tests décrits dans un dépôt professionnel"}},
"scales": {"y": {"beginAtZero": true, "title": {"display": true, "text": "Nombre de fichiers"}}}
}
}
Ma question était simple : comment faire payer une livraison asynchrone freelance IA quand le client ne peut pas confondre une démo convaincante avec une recette vérifiable ? La réponse ne tient pas dans une réunion supplémentaire. Elle tient dans ce que le client peut inspecter seul.
Une promesse différente
Auparavant CTO, j'ai travaillé sur des systèmes Django, PostgreSQL et AWS où la discussion technique finit toujours par rencontrer un décideur qui doit signer. Dans le dépôt examiné, la documentation indique Django ^5.1.2 et Django Ninja ^1.3.0. Je mentionne les versions parce qu'une consigne de recette sans environnement identifié n'est pas reproductible.
L'intuition commerciale voudrait qu'un meilleur agent IA suffise à justifier un TJM supérieur. Les chiffres ne disent pas cela. Le baromètre Malt des tarifs en France affiche, au moment de ma consultation, 575 euros par jour pour les développeurs et 666 euros pour les experts Data. Ces moyennes portent sur des profils de plateforme, pas sur le prix d'un architecte IA donné, et encore moins sur son revenu encaissé.
La fiche Malt des Data scientists affiche 681 euros par jour pour les profils expérimentés actifs durant les trois derniers mois. La dispersion est considérable : la fiche indique 300 euros et moins à une extrémité, 1210 euros et plus à l'autre pour la tranche de 8 à 15 ans d'expérience. Un client ne paie donc pas le mot « architecte ». Il achète un risque réduit et un résultat inspectable.
J'ai retenu une décision de positionnement : proposer un cadrage payant avant de promettre un forfait de construction. Si le corpus, les accès ou les critères de succès ne sont pas fixés, je préfère la régie avec un plafond de jours. C'est une méthode que je propose, pas un taux de closing mesuré sur mes missions. Elle évite de vendre comme certitude ce qui relève encore d'une hypothèse.
Le dossier PREUVE
J'appelle PREUVE le dossier qui rend une remise inspectable sans ma présence. Ce n'est ni un logiciel ni une certification. C'est un protocole de livraison que j'ai formalisé à partir de ce trou dans les tests, en séparant ce qui existait dans le dépôt de ce que j'ajouterais à une mission IA.
Je structure la proposition autour de quatre objets : 1) un périmètre avec exclusions explicites ; 2) un jeu de cas de recette fourni ou validé par le client ; 3) une trace de l'exécution et de ses échecs ; 4) une décision de réception datée. Un architecte vend le passage d'une promesse à une décision. Le développement reste indispensable, mais ne suffit pas.
flowchart LR
A[Devis et périmètre] --> B[Accès et données autorisés]
B --> C[Jeu de cas de recette]
C --> D[Exécution sur environnement identifié]
D --> E[Résultats et incidents]
E --> F{Validation du client}
F -->|Accepté| G[Facture du jalon]
F -->|Réserves| H[Correction dans le périmètre]
H --> D
F -->|Nouveau besoin| I[Avenant chiffré]
Pour un agent documentaire, le jeu de recette doit conserver la question, le document de référence et le comportement attendu. Je refuse de qualifier une réponse « bonne » si le document source manque. Et je sépare les échecs d'accès, les erreurs de retrieval et les réponses non fondées : le client ne doit pas financer à l'aveugle ma recherche du coupable.
Le rythme asynchrone se négocie aussi. Je propose un message de décision à chaque jalon, un référent nommé et une fenêtre de retour inscrite au devis, sans présenter cette fenêtre comme une règle de droit. En cas de silence, je n'invente pas une acceptation automatique. Le mécanisme de recette et ses conséquences doivent être convenus par écrit avec le client.
Ce que les nombres autorisent
Mon audit documentaire donne un constat borné : 3 emplacements de tests vides sur 5 décrits. Il ne démontre ni trois incidents en production ni trois journées perdues. Cette distinction me paraît plus utile qu'un pourcentage décoratif. Elle indique quels scénarios demander avant de transformer une démonstration en réception.
Voici ensuite un calcul de capacité, pas mon historique de facturation. J'applique les deux moyennes du baromètre Malt au même mois fictif, hors charges, frais, prospection et TVA. L'écart vient seulement du nombre de jours facturables et du tarif retenu.
| Hypothèse, non constatée | Jours facturés | Chiffre d'affaires théorique HT |
|---|---|---|
| Développement au repère Malt de 575 euros | 10 | 5750 euros |
| Expertise Data au repère Malt de 666 euros | 8 | 5328 euros |
| Expertise Data au même repère | 9 | 5994 euros |
| Expertise Data au même repère | 10 | 6660 euros |
Le scénario à 8 jours rapporte 422 euros de moins que celui à 10 jours au tarif développeur. Voilà l'intuition renversée : monter son tarif de 91 euros par jour peut diminuer le chiffre d'affaires mensuel si la coordination absorbe deux jours facturables. À 9 jours, l'écart devient positif de 244 euros. La disponibilité vendable compte autant que le tarif affiché.
La tentation serait de prendre deux clients pour remplir les blancs. Mais deux agendas ne produisent pas automatiquement davantage de journées facturables : chacun peut exiger une décision le même mardi. Mon filtre, avant d'accepter une seconde mission, est donc la preuve que chaque client peut avancer sans attendre une réponse synchrone de ma part.
Les fissures du protocole
Dans le même dépôt, la documentation décrit un pipeline de suivi et de sauvegarde encore synchrone, ainsi que des zones de tests non renseignées. Je n'appellerais pas cela une recette réussie. Bien que des parcours soient documentés, je ne peux pas attester la tenue du système sur réseau absent ou sous trafic réel à partir des seuls fichiers consultés.
J'avais d'abord envie de traiter la documentation comme une garantie. C'était une erreur de méthode. Le document atteste qu'un parcours a été pensé ; seul un test exécuté montre ce qu'il fait. Le dossier PREUVE doit donc conserver aussi les échecs et les cas non exécutés, sans maquiller leur statut.
Un forfait sans critères d'acceptation transforme chaque réserve en négociation improvisée. La facture arrive ensuite, escortée de cette question magnifique : « Mais est-ce que c'est vraiment fini ? » J'associe désormais chaque jalon proposé à un livrable observable et à une règle de traitement des demandes hors périmètre. Je recommande de faire relire les clauses contractuelles adaptées à la mission, pas de copier ce paragraphe dans des CGV.
Le prix de l'attente
La trésorerie modifie la conception du delivery. Selon Service Public sur les délais de paiement entre professionnels, le principe général est de 30 jours après la prestation, avec des délais conventionnels encadrés, notamment 60 jours depuis l'émission de la facture ou 45 jours fin de mois sous conditions. Une procédure de vérification peut durer jusqu'à 30 jours en principe ; elle ne décale pas librement le point de départ du paiement.
C'est pour cela que je sépare sur mon modèle de devis le jour de remise, le délai convenu de recette et l'échéance de paiement. Sans ces repères, « livraison vendredi » peut vouloir dire trois dates différentes. Service Public sur la facturation rappelle aussi qu'au 1er septembre 2026, les entreprises françaises concernées doivent pouvoir recevoir des factures électroniques ; l'émission obligatoire arrive le 1er septembre 2027 pour les PME et micro-entreprises.
Une mission multi-clients n'est donc pas seulement un problème de calendrier technique. C'est aussi un portefeuille de décisions et de paiements dont les délais peuvent se superposer. Le marché accélère, certes : Malt Tech Trends 2026 rapporte une demande en agents IA multipliée par 60 en un an sur sa plateforme. Ce signal de recherche ne mesure pourtant ni les contrats signés ni les acomptes reçus.
Les limites du cas
Je n'ai pas de série publiée de mes taux de closing, de mes marges ou de mes délais de recette. Je refuse donc de leur attribuer un gain chiffré. Le dépôt étudié concerne une application de terrain, pas une campagne de missions freelance IA : j'en transpose le défaut de preuve, pas les résultats commerciaux.
Il reste aussi à tester PREUVE sur des livraisons réelles. Je comparerais, avec l'accord des clients, le nombre de réserves qualifiées et le délai entre remise et décision sur deux modalités de livraison. Je suivrais séparément les jours facturables. Cela pourrait être testé sans publier les données du client, mais je ne prétends pas l'avoir déjà fait.
Le changement d'échelle
Un livrable sans recette ressemble à une porte posée devant un terrain vague. La porte peut être belle ; personne ne sait encore si le bâtiment tient. Plus généralement, passer de dev à architecte IA consiste à rendre le risque visible et partageable, pas seulement à augmenter son TJM. Et si ton prochain projet réclame une remise que le client peut vérifier sans t'appeler, regarde mes offres d'architecture IA ou parlons de ton cadrage : je préfère une réserve explicite à une démo immortelle.