Transformer un audit exploratoire IA en mission freelance au périmètre mesurable

Une entreprise peut repartir d’un audit avec plusieurs pistes IA et toujours ne pas savoir quoi acheter ensuite. Comme freelance ou consultant, tu dois décider avec ton client laquelle peut devenir un travail délimité, plutôt que promettre une transformation encore hypothétique.

La série Le choc de l’IA sur le freelancing, au 10 octobre 2026, examine ici ce passage précis. L’exposition de tâches à l’IA, l’usage observé d’outils et les pertes d’emplois sont trois notions différentes. L’une ne prouve pas automatiquement les autres.

Un critère de recette est une condition observable, définie avant le travail, qui permet au client d’accepter ou de refuser un livrable. La méthode qui suit t’aide à préparer une proposition, à poser des limites explicites et à convenir de ces critères. Le premier geste consiste à convertir les constats en une décision de mission, sans transformer une hypothèse en promesse.

À retenir

• Un audit exploratoire éclaire une décision, mais ne vaut pas commande de réalisation.
• Retenir une piste à la fois, avec un problème métier identifiable.
• Vérifier les données, les accès et les conditions d’usage avant de chiffrer.
• Décrire le livrable, les limites et la règle de recette avant de commencer.
• Un arrêt motivé par des risques ou des prérequis manquants reste une décision valable.

Comment transformer un audit exploratoire IA en mission freelance au perimetre ?

Un audit exploratoire ouvre une décision, il ne vaut pas autorisation de construire une solution. Pour passer à une mission de réalisation, transforme un constat en hypothèse testable, puis fais décider au client s’il souhaite financer le travail délimité qui la vérifiera.

L’engagement change quand les deux parties s’accordent sur un livrable, des limites et une règle de recette. Une tâche exposée à l’IA n’est pas forcément automatisée aujourd’hui. Elle ne prouve pas non plus qu’un emploi a été supprimé. L’Organisation internationale du Travail examine les effets possibles de l’IA générative sur les professions dans son article sur les métiers et l’IA générative.

Une piste issue de l’audit devient une mission seulement après une décision explicite, un livrable défini et des limites convenues.

La première étape consiste à reformuler le problème métier sans supposer que l’IA est la bonne réponse. Par exemple, le client peut vouloir réduire le temps passé à retrouver des consignes. L’hypothèse testable pourrait être qu’un outil retrouve les passages pertinents dans un ensemble de documents approuvés.

Il faut ensuite fixer ce qui permettra de décider Go ou No Go. Le client peut autoriser un prototype si les documents sont accessibles et si le résultat peut être vérifié sur des cas représentatifs. Il peut aussi choisir de ne pas poursuivre si les sources sont absentes, les risques trop élevés ou la valeur attendue trop faible.

Les observations d’une plateforme ou d’un fournisseur décrivent leur propre périmètre. Elles ne suffisent pas à tirer une conclusion applicable à tous les freelances, métiers ou entreprises. La publication de l’OCDE sur l’IA générative et les effectifs des PME traite ce sujet dans le contexte des petites et moyennes entreprises.

Une décision positive doit nommer ce qui sera livré et ce qui restera à décider plus tard. Une mission de réalisation peut ainsi commencer par une analyse complémentaire, puis s’arrêter avant l’intégration si un prérequis manque. Passer du principe de la décision aux cas d’usage qu’il est utile de retenir.

Quel cas d’usage mérite une mission de réalisation ?

Un cas d’usage mérite une mission si le problème se répète, si une action améliorée a de la valeur et si son résultat peut être vérifié. Il faut aussi pouvoir limiter les conséquences d’une erreur et désigner un responsable métier qui utilisera le résultat.

Retenir une seule tâche concrète évite de transformer toutes les pistes de l’audit en projets. Un volume fréquent ne suffit pas à justifier une solution : une tâche rare mais sensible peut demander un contrôle renforcé. À l’inverse, une règle simple peut résoudre le besoin sans modèle d’IA.

Le tableau présente quatre exemples entièrement hypothétiques. Les indicateurs sont des idées à tester avec le client, pas des résultats déjà observés. Pour chaque cas, commence par examiner si une règle ou une automatisation classique ferait le travail.

cas d’usage hypothétique	tâche	indicateur à tester	contrôle humain
classer des demandes entrantes	Attribuer une catégorie à chaque message reçu	Catégories correctes sur un échantillon validé	Relecture des cas ambigus, règle simple à tester d’abord
retrouver une procédure	Repérer un passage dans une base documentaire	Passage pertinent retrouvé et source citée	Vérification par le métier, recherche classique à comparer
préparer un compte rendu	Mettre en forme des notes de réunion	Éléments attendus présents sans ajout non confirmé	Relecture avant partage, modèle de document à tester
repérer une anomalie dans un dossier	Signaler une incohérence pour examen	Anomalies connues signalées sur des dossiers test	Décision réservée à une personne, règle métier à comparer

Pour départager les pistes, demande au responsable métier quelle action deviendrait plus simple ou plus fiable. Clarifie ensuite la valeur de cette action pour l’entreprise sans inventer de gain commercial. La réponse peut porter sur la qualité du service, la réduction d’une reprise ou la meilleure visibilité sur une demande.

Un cas prioritaire doit aussi pouvoir être interrompu sans déclencher une action irréversible. Si une erreur peut engager l’entreprise, il faut renforcer le contrôle, limiter le test ou écarter le cas. Une piste prioritaire reste à vérifier contre les données, les accès et les contraintes du système existant.

Les données et les outils permettent-ils de réaliser le cas retenu ?

Une solution techniquement plausible sur un schéma peut devenir irréalisable si le client ne peut pas fournir les données ou les droits nécessaires. Avant de chiffrer un résultat, examine les sources, les formats, la fraîcheur, les accès et les connexions disponibles.

Ne promets pas une réalisation avant d’avoir vérifié les prérequis qui rendent le cas exécutable. Une base mentionnée en réunion peut ne pas être accessible au freelance. Une API, c’est-à-dire une connexion entre logiciels, peut aussi dépendre d’un fournisseur ou d’un compte que le client ne contrôle pas.

Le tableau propose des vérifications concrètes. Chaque ligne indique des tests à effectuer, pas des constats sur un client réel. Note le propriétaire des données, le format fourni et la personne qui autorise leur partage.

point à vérifier	test concret	blocage possible	décision
sources disponibles	Demander un échantillon et nommer son propriétaire	Aucune source exploitable fournie	Obtenir un échantillon ou revoir le cas
droits d’accès	Faire confirmer les droits de lecture et de partage	Autorisation manquante	Attendre l’accord ou arrêter le démarrage
qualité et fraîcheur	Examiner le format, les champs manquants et la date	Fichiers incomplets ou trop anciens	Préparer les données ou réduire le test
contraintes d’intégration	Tester l’API ou la connexion prévue	Accès fournisseur indisponible	Choisir une autre méthode ou chiffrer l’intégration séparément

Vérifie aussi si les données peuvent contenir des informations personnelles. Leur présence peut changer les outils utilisables, les personnes autorisées et le traitement à prévoir. Les dépendances fournisseurs comptent également : une connexion peut être limitée par les conditions du service, ses réglages ou les comptes détenus par le client.

Si l’échantillon est trop petit pour représenter les cas à traiter, un forfait de réalisation serait prématuré. Propose plutôt un audit exploratoire complémentaire pour obtenir les éléments manquants et décider ensuite. Une fois les conditions d’exécution clarifiées, définis comment le client et le freelance reconnaîtront un résultat utile.

Pour les effets de l’IA générative sur le travail dans les PME, tu peux aussi consulter la publication de l’OCDE, consacrée aux effectifs des petites et moyennes entreprises. Elle offre une lecture distincte des vérifications techniques menées pour un cas d’usage particulier.

Comment rendre l’objectif vérifiable ?

« Améliorer le traitement des demandes » ne permet pas au client de décider si le livrable est accepté. Un objectif vérifiable nomme une sortie ou une action observable, ainsi que la manière de l’évaluer dans le contexte du métier.

Un indicateur n’a de sens qu’avec une méthode et un jeu de cas définis. Selon le cas, tu peux mesurer la qualité de la sortie, le temps de traitement, le taux de reprise humaine, le coût variable par tâche ou la gravité des erreurs. Ces mesures ne répondent pas toutes à la même question.

Avant de commencer, prends quatre décisions avec le client :

• Décrire la situation de départ avec les éléments réellement disponibles.
• Choisir un indicateur principal lié à l’action attendue.
• Fixer avec le client le seuil d’acceptation adapté au cas.
• Désigner la personne qui valide les cas limites.

Pour une tâche de préparation de réponse, par exemple, l’équipe pourrait examiner si les informations attendues sont présentes et si une source les appuie. Cette illustration reste une hypothèse : le jeu de cas et la règle de calcul doivent être convenus pour le client concerné.

Le temps de traitement peut être utile, mais il ne suffit pas si la sortie contient des erreurs difficiles à repérer. Le taux de reprise humaine peut aussi cacher des différences entre une correction mineure et une intervention complète. Le coût variable d’un modèle ou d’une infrastructure se distingue, lui, des honoraires du freelance.

Une mesure sur un prototype ne garantit pas un gain financier en production. Elle porte sur les cas testés, dans des conditions choisies. Pour poursuivre ta veille, la page de l’Economic Index d’Anthropic est une lecture consacrée à l’indice économique associé à l’IA.

Formule l’objectif avec des mots que le responsable métier peut contrôler : quelle sortie regarder, sur quels cas et avec quelle règle d’acceptation. Utilise l’objectif vérifiable pour bâtir une proposition qui transforme l’audit en étapes et en décisions.

Que doit contenir la proposition de mission ?

Une proposition utile relie le problème métier à un cas retenu, décrit les étapes et rend le budget compréhensible. Elle permet au client de choisir la suite sans confondre une estimation, une hypothèse et un résultat garanti.

Fais apparaître quatre éléments : le constat, le périmètre, la feuille de route et le modèle budgétaire. Cette structure facilite la décision et évite que l’offre se limite à une liste d’outils ou de compétences.

Relier les constats de l’audit au problème métier

Commence par décrire le problème tel que le client l’a formulé. Nomme le cas d’usage retenu, les constats établis pendant l’audit exploratoire et les hypothèses restant à vérifier. Un lecteur doit comprendre pourquoi cette mission répond à un besoin précis, sans devoir deviner ce que tu as observé.

Si plusieurs pistes ont été discutées, explique pourquoi l’offre porte sur une seule d’entre elles. Tu peux rappeler qu’une règle simple ou une automatisation classique reste une option à examiner. Cette franchise aide le client à comparer la mission à d’autres façons de résoudre son problème.

Décrire les étapes, les livrables et les décisions

Présente la séquence de travail : exploration complémentaire, prototype ou pilote, recette, puis éventuel passage en production. Précise ce que reçoit le client à chaque étape, ainsi que la décision attendue avant de poursuivre. Un prototype peut servir à tester une hypothèse sans inclure l’intégration à ses outils quotidiens.

Dans un exemple hypothétique, une entreprise pourrait financer un prototype de recherche documentaire, puis décider si un pilote limité mérite d’être préparé. Aucune étape ne doit apparaître comme automatique. La suite dépend des résultats observés, des prérequis et de l’accord du client.

Présenter le budget, les hypothèses et les conditions

Indique le mode de facturation et les échéances de paiement proposés. Décris les contributions attendues du client, comme la fourniture d’un échantillon ou la disponibilité d’un responsable métier. Mentionne les hypothèses qui peuvent modifier le chiffrage, par exemple un accès technique absent ou une source de données différente.

Si tu présentes une estimation de retour sur investissement, distingue-la clairement d’un résultat acquis. Elle repose sur des hypothèses que le client peut discuter, pas sur une performance garantie. Une proposition convaincante montre comment chaque constat de l’audit devient une décision ou un livrable identifiable, mais elle reste incomplète tant que ses frontières ne disent pas précisément ce que le client achète.

Que faut-il inclure et exclure du périmètre ?

Le périmètre doit nommer le processus concerné, les sources autorisées, les fonctions incluses, les utilisateurs visés et le livrable. Il doit aussi rendre visibles les exclusions et les contributions attendues du client.

Une demande qui n’est pas décrite ne devient pas automatiquement une tâche comprise dans la mission. Pour une mission IA, précise notamment si l’outil propose une réponse, la rédige ou l’envoie. Ces actions n’impliquent pas le même niveau de travail ni le même besoin de validation.

Écrire les inclusions en termes observables

Décris l’activité visée avec des verbes concrets : classer une demande, rechercher une procédure ou préparer un brouillon. Nomme les sources que l’outil peut consulter et les fonctions comprises dans le livrable. Indique aussi les utilisateurs concernés et le format de ce qu’ils recevront.

Un exemple hypothétique pourrait inclure un assistant qui recherche des passages dans une base documentaire approuvée, puis fournit une réponse avec les références correspondantes. Il ne faut pas présenter cet exemple comme un engagement réel. Le contenu exact dépend des besoins, des outils et des accès convenus avec le client.

Nommer les exclusions et les responsabilités du client

Écris ce qui n’est pas compris : intégrations non prévues, volumes non convenus, maintenance après livraison ou révisions supplémentaires. Précise quelles données le client doit fournir et quelle personne validera les actions sensibles. Une validation humaine ne doit pas rester une formule vague si elle conditionne l’usage.

Vérifie en particulier ces quatre clauses de périmètre :

• Le système ou l’environnement informatique concerné.
• Les données et les accès que le client s’engage à fournir.
• Le traitement des changements hors périmètre.
• La responsabilité de validation côté client.

Dans un scénario hypothétique, le client demande une connexion à son CRM après avoir validé un livrable sans intégration. Cette nouvelle demande peut modifier les accès nécessaires, le travail et les tests. Il faut la comparer au périmètre, puis convenir de son traitement avant de la commencer.

Décrire ces frontières protège la relation de travail autant que le budget. Après avoir borné la mission, traduis les promesses de performance en critères de recette discutés avant le développement.

Quels critères de recette choisir pour une mission IA ?

Un livrable IA n’est acceptable que si les deux parties savent à l’avance quelles erreurs sont tolérables et lesquelles ne le sont pas. Le critère de recette doit être observable, lié au risque et défini avant les tests.

Un seuil n’est pas universel : c’est une décision de mission à prendre avec le client. Il dépend du cas, de la gravité d’une erreur et de la manière dont les utilisateurs agiront sur les résultats. Évite donc d’accepter la formule « assez intelligent » comme règle de validation.

Mesurer les sorties sur un jeu de cas défini

Prépare un jeu de test composé d’exemples représentatifs fournis ou validés par le client. Il doit couvrir des cas ordinaires, des demandes ambiguës et des situations défavorables. Une sortie qui convient sur une requête simple ne dit pas comment le système réagit à une information contradictoire.

Le jeu de cas sert à observer le comportement dans des conditions connues. Il ne représente pas nécessairement toutes les situations rencontrées en production. Le client peut contribuer à choisir les exemples, à confirmer les réponses attendues et à repérer les cas qui exigent un contrôle particulier.

Fixer la règle d’acceptation et le traitement des erreurs

Choisis un indicateur et écris sa méthode de calcul. Convenez ensuite d’un seuil adapté au risque, d’une option d’abstention ou d’escalade humaine, ainsi que du délai de correction à appliquer si un test échoue. Le délai doit être établi entre les parties, selon leur capacité à traiter les retours.

Les tests peuvent couvrir quatre familles :

• Qualité de sortie sur les demandes ordinaires.
• Cas limites ou formulations ambiguës.
• Erreurs à fort impact pour le métier.
• Comportement quand une source d’information manque.

Si une information manque, le système peut devoir l’indiquer au lieu de produire une réponse incertaine. Si un cas touche une action sensible, la règle peut imposer une validation par une personne. Ces comportements font partie du livrable à évaluer, pas d’une appréciation subjective après coup.

Une mesure sur un jeu de test décrit ce que l’équipe a observé dans ces conditions. Elle ne garantit pas une performance identique en production, où les demandes et les sources peuvent évoluer. Des critères mesurables permettent ensuite de choisir une facturation compatible avec les incertitudes restantes.

Forfait par jalons ou régie pilotée : quel mode choisir ?

Le mode de facturation dépend moins du mot « IA » que de ce qui reste à apprendre avant de pouvoir livrer. Le forfait par jalons convient mieux quand les données, les accès et les livrables sont assez clairs pour délimiter chaque étape.

Choisis le mode qui rend visibles les inconnues, sans faire croire qu’un forfait couvre tout changement. La régie pilotée peut convenir si l’exploration technique comporte encore des inconnues. Elle demande des objectifs de fin de sprint et un suivi du temps partagé avec le client.

mode	à privilégier si	avantage	vigilance
forfait par jalons	Accès, données et livrables sont définis	Montant convenu par étapes	Les changements ne sont pas inclus implicitement
régie pilotée	Des inconnues techniques restent à explorer	Temps suivi et objectifs de sprint visibles	Le suivi et les décisions doivent rester réguliers
combinaison de phases	Le diagnostic est ferme, la réalisation plus exploratoire	Chaque phase porte un engagement adapté	Prévoir une décision entre les phases

Réserver le forfait aux hypothèses suffisamment stabilisées

Un forfait par jalons fonctionne mieux quand tu peux dire ce qui sera remis et comment chaque livrable sera vérifié. Les accès sont identifiés, les données utiles sont disponibles et les limites ont été discutées. Les demandes nouvelles peuvent alors être examinées séparément, plutôt que supposées comprises.

Le montant convenu par étapes n’élimine pas les incertitudes. Il les rend gérables lorsque les hypothèses sont suffisamment explicites. Si une intégration dépend encore d’un accès qui n’a pas été testé, il faut signaler ce risque avant de figer l’engagement.

Utiliser la régie pilotée quand l’incertitude doit être explorée

La régie pilotée convient mieux lorsque le travail consiste aussi à découvrir ce que les données ou l’environnement technique permettent. Fixe un objectif concret à la fin de chaque sprint et partage le temps consacré, les résultats obtenus et les obstacles rencontrés.

Une combinaison peut commencer par un diagnostic au périmètre ferme, puis prévoir une réalisation plus exploratoire. Le client décide alors de poursuivre à partir d’éléments plus solides. Après avoir choisi un modèle d’engagement, estime le travail complet, y compris les échanges et les validations.

Comment estimer la charge sans sous-chiffrer ?

Le temps passé à vérifier les données et à obtenir des validations peut dépasser celui consacré au premier prototype. Pour estimer la charge, compte toutes les tâches nécessaires au livrable, pas seulement la construction de la démonstration.

Décompose le travail par activité et rends visibles les hypothèses encore incertaines. Inclue le cadrage, l’accès et la préparation des données, la conception, l’intégration, les tests, les retours client, la documentation, le transfert et l’éventuelle supervision.

Évalue ces postes séparément, puis vérifie leurs dépendances. Par exemple, l’intégration ne peut pas être estimée comme certaine si l’accès au système n’a pas été testé. Les retours client ont aussi besoin d’un interlocuteur disponible et d’une manière convenue de regrouper les commentaires.

Ajoute une marge de discussion pour les hypothèses non vérifiées, sans inventer de pourcentage. Explique au client ce qui pourrait faire évoluer la charge : données plus complexes que prévu, accès tardifs ou changement de besoin. Si ces incertitudes dominent le travail, propose d’abord une étape de vérification limitée.

Les honoraires ne sont pas les seuls coûts du projet. Isole les coûts variables des modèles et de l’infrastructure pour que le client sache ce qui dépend de l’usage. Le client peut détenir ses propres comptes fournisseurs, ce qui change la gestion des accès et le suivi des consommations.

Un devis au forfait est prématuré si l’échantillon de données ou l’accès technique manque. Dans ce cas, distingue ce que tu peux chiffrer de ce qui dépend encore d’un test ou d’une décision du client. Un chiffrage réaliste rend visibles les dépendances, mais il doit aussi rendre visibles les risques de données, d’usage et de sécurité.

Quelles limites et précautions intégrer dès le départ ?

Une mission IA peut être faisable tout en restant inadaptée si les données utilisées ou les actions possibles ne sont pas acceptables pour le client. Avant tout traitement, clarifie les informations concernées, les accès nécessaires et les effets possibles des sorties.

Définis les limites d’usage avant de donner au système accès aux données ou la capacité d’agir. La nature des données, leur destination et leur traitement par les fournisseurs comptent autant que le fonctionnement technique. Les recommandations de la CNIL sur l’utilisation d’un système d’IA générative abordent les précautions liées aux données personnelles et à leur usage.

Encadrer les données, les accès et la confidentialité

Identifie les données nécessaires et écarte celles qui ne servent pas au cas d’usage. Détermine qui peut accéder aux sources, où les données sont envoyées et comment les fournisseurs les traitent. Examine aussi les contrats applicables aux outils choisis et les éventuels transferts de données hors de l’Union européenne.

La CNIL recommande d’évaluer les risques, de limiter l’envoi de données sensibles à des services externes et d’examiner les contrats et transferts concernés. Elle rappelle aussi l’intérêt de former les utilisateurs et de vérifier les réponses générées, qui peuvent être inexactes ou biaisées. Ces précautions doivent se traduire dans les choix concrets de la mission.

Limiter l’autonomie et prévoir une intervention humaine

Indique qui valide une action sensible et dans quelles situations le système doit s’abstenir ou demander de l’aide. Définis comment arrêter le fonctionnement et qui prend en charge une erreur signalée. Un agent qui prépare une action n’a pas besoin de recevoir automatiquement le droit de l’exécuter.

Pour toute fonction qui touche un dossier, un paiement ou une communication importante, identifie la personne qui garde la décision. Prévois une reprise humaine compréhensible, plutôt qu’une consigne générale qui ne précise ni responsable ni geste à effectuer.

Vérifier les obligations applicables sans promettre la conformité

Distingue les faits juridiques en vigueur, les textes en projet et les scénarios de travail. Ne présente pas une hypothèse ou une évolution annoncée comme une obligation déjà applicable. Les exigences peuvent dépendre du secteur, des données et du rôle précis du système.

Pour tes recherches, privilégie les sources primaires de l’OIT, de l’OCDE, de l’INSEE, de la CNIL, de l’ANSSI et de la Commission européenne, ainsi que les travaux de recherche originaux. Toute donnée reprise doit garder sa date et son périmètre. Une lecture générale ne remplace pas un avis adapté à une situation particulière.

Discute quatre contrôles avec le client :

• Les données réellement nécessaires au cas.
• Les droits d’accès minimaux pour réaliser le travail.
• La validation humaine des sorties ou actions sensibles.
• La procédure d’arrêt et la personne responsable.

Un cas à fort impact peut nécessiter une analyse spécialisée avant toute mise en œuvre. Définir ces limites avant de construire aide à décider quelles phases livrer et à quel moment arrêter ou poursuivre.

Quels livrables prévoir du prototype à la production ?

Un prototype vérifie qu’un chemin technique existe, un pilote teste un usage limité et la production organise un fonctionnement suivi. Ces étapes ne sont pas interchangeables : chacune doit répondre à une question et déboucher sur une décision.

Une démonstration qui fonctionne sur quelques exemples ne prouve pas qu’un système est prêt à être utilisé au quotidien. Distingue ce qui est montré, ce qui est testé avec des utilisateurs et ce qui sera exploité en continu.

phase	question traitée	livrable	décision suivante
prototype	Un chemin technique répond-il à l’hypothèse ?	Démonstrateur sur un périmètre de test	Préparer un pilote ou arrêter
pilote	Un usage limité est-il exploitable ?	Essai encadré avec suivi des retours	Corriger, étendre ou interrompre
production	Le service peut-il être suivi au quotidien ?	Système supervisé, documenté et transféré	Maintenir, ajuster ou arrêter

Livrer un prototype pour tester une hypothèse

Le prototype montre qu’un chemin technique peut exister dans les conditions du test. Il ne garantit ni la stabilité ni le comportement sur toutes les données. Le livrable doit préciser ce qui a été essayé, avec quelles sources et quelles limites restent ouvertes.

Dans un exemple hypothétique, un assistant de recherche documentaire pourrait retrouver des passages dans un ensemble de documents approuvés. Cette démonstration ne prouverait pas qu’il répond correctement à toutes les demandes ou que son intégration est prête.

Encadrer un pilote en conditions limitées

Le pilote teste un usage dans des conditions contrôlées, auprès d’un groupe ou sur des sources délimitées. Une validation humaine peut rester nécessaire pour les actions sensibles. Décris qui participe, quelles situations sont exclues et comment les retours sont recueillis.

Dans le même exemple hypothétique, le client pourrait tester l’assistant sur des documents approuvés avant d’élargir les sources. L’extension ne vient qu’après examen des résultats et validation des risques. Le pilote peut aussi révéler qu’un processus doit être ajusté avant toute intégration plus large.

N’ouvrir la production qu’avec supervision et transfert

La production suppose une supervision, une gestion des incidents, une mesure continue et un interlocuteur responsable. Elle demande aussi une documentation adaptée et un transfert clair vers les personnes qui suivront le système. Sans ces éléments, un outil livré risque de ne pas avoir de responsable au quotidien.

Décider de passer en production implique donc un nouvel accord sur les conditions d’exploitation. Même découpée en étapes, une mission peut évoluer; il faut donc prévoir comment traiter chaque demande nouvelle.

Comment gérer les changements et arrêter si nécessaire ?

Une nouvelle source de données peut modifier à la fois les risques, le travail et le résultat attendu. Compare chaque demande nouvelle au périmètre avant d’accepter de la traiter.

Décide pour chaque changement de l’écarter, de le substituer à une tâche prévue ou de le chiffrer séparément. Cette décision évite de laisser une demande s’ajouter silencieusement au travail déjà convenu.

Traiter une nouvelle demande comme une décision de périmètre

Reprends la demande et compare-la au livrable, aux outils et aux sources prévus. Dans un exemple hypothétique, le client souhaite brancher une nouvelle source après le début du pilote. Cette connexion peut exiger d’autres droits, des tests supplémentaires ou une nouvelle méthode de validation.

Présente les options de façon concrète : ne pas intégrer la source, remplacer un élément déjà prévu ou chiffrer cette évolution à part. Demande un accord avant de modifier les tâches en cours. Toute formulation contractuelle doit être examinée et validée par les parties compétentes, selon leur situation.

Prévoir un point Go ou No Go sur les blocages

Fixe un point de décision si les données, les accès ou les résultats de test ne permettent pas de poursuivre dans les conditions convenues. Le Go confirme la suite définie; le No Go arrête la phase ou renvoie les parties à une nouvelle décision.

La formulation opérationnelle peut préciser le constat attendu : l’accès nécessaire est disponible, l’échantillon permet le test prévu ou les résultats sont interprétables. N’invente pas un délai ou un seuil qui n’a pas été discuté. Indique ce qui sera examiné et qui participe à la décision.

Les travaux effectivement réalisés et leur facturation doivent être traités selon l’accord conclu entre les parties. Une phrase générique ne constitue pas une règle juridique universelle. La règle de changement doit être compréhensible pour le client et compatible avec les modalités convenues.

Un point No Go n’est pas un échec si une condition importante n’est pas réunie. Il évite de poursuivre un projet dont les données ou les résultats contredisent les hypothèses initiales. Une règle de changement claire prépare la discussion de validation de la proposition avec le client.

Comment faire valider la proposition par le client ?

Une proposition n’est acceptée que si le client sait qui décide, ce qu’il valide et ce qui se passe ensuite. Demande une confirmation explicite plutôt qu’un « on verra » qui ne réserve ni décision ni responsabilité.

Fais confirmer le responsable métier, les personnes qui valident les données et les actions, ainsi que les accès fournis par le client. Demande aussi si les exclusions sont comprises et quelle est la prochaine décision attendue.

Une question utile porte sur le risque : quelle hypothèse le client juge-t-il la plus incertaine ? Sa réponse peut faire ressortir un accès difficile, une source peu fiable ou une étape qui mérite un test séparé.

Si le décideur n’assiste pas à l’échange, ne traite pas son absence comme un accord implicite. Obtiens sa validation avant de réserver la capacité de réalisation. Un accord sur l’objectif ne signifie pas encore un accord sur le périmètre et le budget.

La conversation doit aboutir à une décision pratique : accepter l’offre, demander une modification ou suspendre le projet. Une fois le cadre accepté, vérifie quel statut et quel mode de gestion conviennent au freelance, sans détourner la discussion vers un guide administratif général.

Le portage salarial est-il pertinent pour cette mission ?

Le portage salarial peut répondre à une préférence de gestion, mais il ne rend pas une mission mal cadrée plus sûre. Un consultant peut l’envisager s’il souhaite déléguer une partie de la gestion administrative tout en réalisant la prestation.

Le portage ne définit ni le périmètre, ni les critères de recette, ni les responsabilités opérationnelles. Ces éléments restent à convenir avec le client, quel que soit le parcours ou le profil du freelance.

Cette option n’est pas une étape obligatoire pour convertir un audit exploratoire en offre de réalisation. Elle ne remplace ni le choix d’un cas métier, ni les échanges sur les données et les livrables. Elle concerne plutôt la façon dont le consultant souhaite gérer son activité.

Vérifie l’adéquation du portage avec ta situation et les règles applicables auprès des interlocuteurs compétents. Les besoins diffèrent selon le parcours, le métier et l’organisation du travail; une réponse générale ne suffit pas à déterminer ce qui convient à chacun.

Tu peux maintenant repartir de l’audit avec une prochaine action concrète et une estimation indicative, sans confondre estimation et revenu promis.

Quelle action mener dès la fin de l’audit ?

Avant de quitter l’audit, choisis une seule piste et demande au client de confirmer ses prérequis. Cette demande transforme une analyse en décision concrète, sans laisser les incertitudes se glisser dans une promesse.

Consigne les points encore ouverts et ne les présente pas comme des résultats acquis. Une action courte vaut mieux qu’une proposition qui empile des cas d’usage, des accès non confirmés et des fonctions imaginées.

À la fin de l’audit, demande au client de confirmer une piste, ses prérequis et la prochaine décision avant d’engager la réalisation.

Tu peux envoyer au client quatre éléments à traiter :

• Choisir un seul cas d’usage prioritaire.
• Envoyer les hypothèses et les prérequis à confirmer.
• Transmettre une proposition qui nomme les livrables et les exclusions.
• Convenir d’un point Go ou No Go pour décider de la suite.

Si le portage salarial fait partie de tes options, le simulateur de portage salarial peut fournir une estimation indicative. Il ne garantit aucun revenu et ne remplace pas l’examen de ta situation individuelle auprès des interlocuteurs compétents.

Garde une trace des accès attendus, des données à fournir et des questions sans réponse. Le client peut confirmer certains points avant de donner son accord sur la réalisation. Demande maintenant la confirmation de la piste retenue et des conditions nécessaires au livrable.

Conclusion

Un audit utile ne se mesure pas au nombre de pistes qu’il produit, mais à la qualité de la décision qu’il permet de prendre. Une mission de réalisation commence quand un cas d’usage, un périmètre, un livrable et une règle de validation sont convenus.

Le client et le freelance peuvent aussi décider de ne pas poursuivre. Des données insuffisantes, des risques trop élevés ou une valeur attendue trop faible peuvent rendre la réalisation inadaptée. Cette décision évite de transformer une hypothèse de l’audit en promesse.

Avant tout début de travail, demande au client une validation écrite du cas retenu, des prérequis et du livrable prévu.

FAQ

Faut-il forcément construire un prototype après un audit exploratoire IA ?

Non, un prototype n’est utile que s’il réduit une incertitude qui compte pour la décision. Si les données nécessaires ne sont pas accessibles, si le cas paraît trop risqué ou si une méthode plus simple suffit, tu peux recommander de ne pas le construire. L’audit peut alors aboutir à un arrêt motivé, plutôt qu’à une étape technique sans utilité claire.

Comment facturer la préparation des données découverte après l’audit ?

Vérifie d’abord si la préparation des données figure parmi les tâches comprises dans le périmètre convenu. Si elle n’y apparaît pas, traite-la comme une modification à estimer et à faire valider avant de commencer. Décris les fichiers concernés, les opérations prévues et le livrable attendu, afin que le client puisse décider s’il souhaite ajouter ce travail.

Qui doit fournir les données et les accès pour démarrer la mission ?

Le client doit désigner un responsable et confirmer qu’il a les droits nécessaires pour partager les données. Le périmètre doit nommer les sources attendues, les accès à fournir et leur usage prévu. Si un accès dépend d’un fournisseur ou d’une équipe interne, note cette dépendance et demande une confirmation avant de considérer le démarrage comme possible.

Peut-on garantir un taux de réussite pour une solution IA ?

Pas sans jeu de test défini, méthode de calcul, gravité des erreurs et conditions d’usage convenues. Un résultat mesuré sur quelques exemples ne décrit pas automatiquement le fonctionnement en production. Propose plutôt un seuil à décider avec le client sur des cas représentatifs, puis distingue clairement cette mesure d’une garantie générale de performance.

Que faire si le client demande une nouvelle fonction en cours de réalisation ?

Compare la demande au périmètre déjà convenu, puis décide avec le client de l’écarter, de la substituer à une tâche prévue ou de la chiffrer séparément. Décris l’effet sur les données, les outils, le travail et les tests avant de commencer. Fais confirmer par écrit la décision et les changements retenus.

Le passage en production peut-il être inclus d’office dans le forfait du pilote ?

Non, sauf si la production a été explicitement prévue avec ses conditions propres. Le périmètre doit alors préciser la supervision, les accès, les critères de recette, la gestion des incidents et les responsabilités quotidiennes. Un pilote teste un usage limité; il ne comprend pas automatiquement l’exploitation continue ni le transfert aux équipes du client.