IA pour la gestion de projet : cas d'usage concrets pour freelances

L’IA ne gère pas un projet freelance, elle réduit quatre corvées : transformer un échange en compte rendu, tenir la liste des actions, repérer ce qui sort du périmètre signé, relancer au bon moment. Tout le reste (arbitrer, négocier, dire non à un client) reste chez vous. Après avoir branché Claude API sur mon propre suivi de projet, mon avis est net : le gain est réel, mais il vient des petites tâches répétitives, pas d’un « assistant projet » censé tout piloter.

Voici les usages que je garde, un exemple chiffré, ceux que je refuse d’automatiser et les précautions RGPD à prendre.

L’idée reçue : l’IA ne remplace pas votre chef de projet, parce que vous n’en avez pas

Beaucoup de contenus présentent l’IA comme un chef de projet virtuel. En freelance, le problème est ailleurs : vous êtes seul, vous cumulez le commercial, la production et le suivi, et ce qui saute en premier, c’est le suivi. Un compte rendu non écrit, une validation orale jamais notée, un « petit ajout » accepté au téléphone.

Je ne cherche donc pas un outil qui planifie à ma place. Je cherche à rendre le suivi assez peu coûteux pour qu’il soit fait à chaque fois. Un compte rendu qui prend 3 minutes au lieu de 20 est un compte rendu qui existe.

Usage 1 : du message ou de l’appel au compte rendu daté

Après un appel ou un échange de mails, je colle mes notes brutes (ou la transcription) dans un script qui appelle Claude API. Il me rend un compte rendu en quatre blocs : décisions prises, actions avec responsable, questions ouvertes, prochaine échéance.

Pour que la sortie soit exploitable, j’utilise les sorties structurées d’Anthropic, qui contraignent la réponse à un schéma JSON, et je valide en plus avec Zod côté code. Une action sans responsable ou sans date est rejetée et je la complète à la main. Le script ajoute ensuite le résultat à un fichier Markdown versionné dans le dépôt du projet.

Ma règle : le compte rendu est envoyé au client après relecture par moi. Le modèle peut attribuer une décision à la mauvaise personne, et ce document sert de preuve en cas de désaccord.

Usage 2 : comparer chaque nouvelle demande au périmètre signé

C’est l’usage qui a le meilleur rapport valeur/effort, et celui dont on parle le moins. Je garde le périmètre du devis dans un fichier (liste des pages, fonctionnalités, nombre d’allers-retours inclus). Quand un client écrit « tu pourrais aussi ajouter… », je passe le message et le périmètre au modèle avec une consigne fermée : répondre dans_le_perimetre, hors_perimetre ou ambigu, avec une phrase de justification.

Prenons un exemple, présenté comme une illustration et non comme une mesure : un site de vitrerie locale comme vitriersparis.fr, avec un devis couvrant 6 pages, un formulaire de demande d’intervention et un affichage des zones desservies. En cours de route, le client demande un module de prise de rendez-vous en ligne avec agenda. Le modèle classe la demande en hors_perimetre, car aucun agenda n’est listé, et cite la ligne du devis qui le prouve. Je n’ai plus qu’à chiffrer l’ajout, au lieu de me demander une heure plus tard si je l’avais promis ou non.

Le piège : le modèle ne connaît pas le contexte oral. Une demande classée hors_perimetre peut avoir été évoquée en rendez-vous. C’est pourquoi ambigu existe, et pourquoi je ne réponds jamais au client sans avoir relu.

Usage 3 : relances et points d’étape

Les relances sont la corvée que je repousse le plus : contenus à fournir, validation de maquette, paiement d’acompte. Mon script lit la liste des actions en attente, repère celles qui dépassent 5 jours ouvrés et prépare un brouillon de relance par client, avec le contexte exact (quel livrable, quelle date, ce que ça bloque).

Je ne l’envoie jamais automatiquement. Un brouillon arrive dans ma boîte, je le relis, je l’envoie. Pourquoi ? Une relance automatique mal calibrée envoyée à un client agacé abîme une relation qui a pris des mois à construire. Deux minutes de relecture coûtent moins cher.

Usage 4 : la checklist de recette

Avant la livraison d’un site, je fais générer une checklist de recette à partir du périmètre : chaque page, chaque formulaire, chaque comportement promis devient une ligne à cocher. Le modèle ajoute des vérifications que j’oublie parfois (page 404, mentions légales, bandeau cookies si l’analytics n’est pas anonyme, redirections).

J’y ajoute mes contrôles de performance habituels. La checklist est un point de départ que je complète, pas une garantie d’exhaustivité.

Ce que je n’automatise pas

Tâche	Pourquoi je la garde
Fixer un prix ou un délai	Dépend de la relation, de la qualité des contenus et de ma charge, hors de portée du modèle
Répondre à un client mécontent	Le ton se joue sur un détail, une erreur coûte un contrat
Décider d’accepter ou refuser un ajout	C’est un arbitrage commercial, le modèle ne voit pas l’enjeu

Je m’en sers pour préparer ces décisions (rappeler l’historique, relever l’écart), pas pour les prendre.

RGPD : vos échanges clients sont des données personnelles

Un compte rendu contient des noms, des adresses email, parfois des numéros de téléphone. Les envoyer à une API relève donc du RGPD, même quand vous êtes un entrepreneur individuel. Ma pratique tient en cinq points :

1. Offre API commerciale uniquement, pas un compte grand public. Je relis les conditions d’Anthropic sur l’entraînement et la durée de conservation avant de brancher un nouveau flux, parce qu’elles évoluent.
2. Minimisation. Je retire les téléphones, adresses et tout ce qui n’aide pas à produire le compte rendu avant l’envoi.
3. Aucune donnée sensible (santé, situation financière détaillée d’un particulier) dans ces flux.
4. Registre. L’outil figure dans mon registre des traitements, avec sa finalité : suivi de projet.
5. Information des clients. Une ligne dans mes conditions : certains documents de suivi sont rédigés avec l’aide d’un outil d’IA, relus par moi.

La CNIL publie des fiches pratiques sur l’IA et le RGPD, utiles pour cadrer ce point. Elles sont rédigées surtout pour qui développe des systèmes d’IA, mais leur logique (finalité claire, minimisation, sécurité) s’applique à un usage de freelance.

Mise en route : un week-end, pas un projet

Si vous partez de zéro, voici le chemin le plus court :

1. Un fichier de suivi par projet dans un dépôt Git ou un dossier, avec le périmètre signé en tête.
2. Un script de compte rendu (usage 1), à tester sur 3 projets passés pour voir où le modèle se trompe.
3. Le contrôle de périmètre (usage 2), qui est celui dont le retour est le plus rapide.
4. Les relances et la recette une fois les deux premiers stabilisés.

Dans ma pratique, je compte 2 à 3 heures récupérées sur un site vitrine de 4 à 6 semaines. C’est une estimation à partir de mon propre suivi, pas un chiffre publié. À un TJM de 400 euros, 2 heures de moins en tâches de suivi, c’est peu sur un projet, mais cela s’additionne sur une année de 15 à 20 projets. Le vrai bénéfice se voit ailleurs : moins d’oublis, moins de désaccords sur ce qui était inclus.

Quand ce n’est pas la peine

Si vous menez 2 ou 3 projets par an, un modèle de compte rendu dans un traitement de texte suffit et l’automatisation coûterait plus de temps qu’elle n’en rend. Si vos clients échangent surtout par téléphone sans que vous preniez de notes, le problème est en amont : aucune IA ne résume un appel qui n’a pas été noté. Je place le seuil autour d’une dizaine de projets par an. En dessous, soignez d’abord l’habitude d’écrire.

Ce qu’il faut retenir

L’IA aide un freelance sur quatre tâches de suivi : compte rendu daté, contrôle de périmètre par rapport au devis signé, brouillons de relance et checklist de recette. Elle ne doit ni chiffrer, ni arbitrer, ni écrire seule au client. Branchez Claude API avec des sorties structurées validées par Zod, relisez tout avant envoi, utilisez une offre commerciale, minimisez les données personnelles et inscrivez le traitement à votre registre RGPD. Sous une dizaine de projets par an, un simple modèle de compte rendu suffit.

Les points clés

• Visez le suivi qui saute en premier (comptes rendus, validations notées), pas un assistant qui « pilote » votre projet.
• Comparez chaque nouvelle demande client au périmètre du devis avec une liste fermée de réponses : dans le périmètre, hors périmètre, ambigu.
• Ne laissez aucune relance ni aucun compte rendu partir sans votre relecture.
• Gardez le prix, le délai et l’arbitrage d’un ajout pour vous : le modèle ne voit pas la relation.
• Traitez vos échanges clients comme des données personnelles : offre API commerciale, minimisation, registre, information du client.
• Sous une dizaine de projets par an, soignez l’habitude d’écrire avant d’automatiser.