Vos prototypes bricolés à l'IA sont le meilleur cahier des charges que je reçois

Le cahier des charges classique est un document mort. Il décrit des besoins supposés, rédigés à un instant T, souvent par quelqu'un qui n'utilisera jamais l'outil final. Selon les bonnes pratiques de gestion de projet, un cahier des charges doit pourtant traduire fidèlement le besoin fonctionnel du commanditaire. Le problème, c'est que ce besoin est rarement clair au départ.

Depuis deux ans, je reçois de plus en plus de briefs d'un genre nouveau. Des dirigeants de PME arrivent avec un prototype fonctionnel. Pas un document Word de 40 pages. Un outil qui tourne. Bricolé avec ChatGPT, Cursor, Bolt, ou un assemblage de no-code et de scripts générés par IA. Et ce prototype, aussi imparfait soit-il, contient plus d'informations utiles que n'importe quel cahier des charges formel que j'ai lu en quinze ans de métier.

Pourquoi ? Parce qu'il a été confronté à la réalité. Le dirigeant l'a utilisé, ses équipes l'ont testé, et les fonctionnalités inutiles ont déjà été éliminées. Ce qui reste, c'est le besoin réel, filtré par l'usage.

Un prototype vaut mille pages de spécifications

Un cahier des charges traditionnel repose sur des hypothèses. Le rédacteur imagine les parcours utilisateurs, anticipe les cas d'usage et tente de prévoir les exceptions. C'est un exercice intellectuel utile, mais intrinsèquement limité. Comme le soulignent les méthodologies de conduite de projet, la bonne compréhension du besoin par toutes les parties prenantes est le facteur critique de succès d'un projet informatique.

Le prototype bricolé par le client résout ce problème d'une manière que le document écrit ne peut pas atteindre. Quand un dirigeant me montre un tableur connecté à une API via un script Python généré par IA, je vois immédiatement :

• Les données qu'il manipule réellement, pas celles qu'il pense manipuler
• L'ordre dans lequel il effectue ses opérations
• Les cas limites qu'il a découverts en utilisant son outil
• Les fonctionnalités qu'il a ajoutées en cours de route parce que le besoin est apparu à l'usage

Ce n'est pas du code à jeter. C'est une spécification exécutable. Chaque ligne, même maladroite, encode une décision métier que le dirigeant a prise en connaissance de cause. Un cahier des charges écrit aurait peut-être omis la moitié de ces décisions, simplement parce qu'elles paraissent évidentes à celui qui connaît son métier.

Le dirigeant qui bricole comprend mieux son propre besoin

Il y a un bénéfice que personne ne mentionne dans les guides de rédaction de cahier des charges : le processus de prototypage force le commanditaire à clarifier sa pensée.

Rédiger un document de spécification, c'est décrire un système de l'extérieur. Construire un prototype, même rudimentaire, c'est le vivre de l'intérieur. Le dirigeant qui passe trois soirées à assembler un outil avec Bubble ou à demander à Claude de lui générer un script d'automatisation découvre des choses sur son propre workflow qu'il n'avait jamais formalisées.

J'ai vu un gérant de PME industrielle arriver avec un prototype d'outil de suivi de production fait sous Airtable, enrichi de formules générées par IA. Son cahier des charges initial tenait en une phrase : "je veux suivre ma production". Son prototype, lui, révélait 14 règles métier distinctes, trois niveaux de priorité et un système d'alerte par seuil qu'il avait inventé sans s'en rendre compte.

Ce niveau de détail, aucun atelier de cadrage n'aurait pu l'extraire en deux heures de réunion. Le prototypage est un outil de découverte du besoin, pas seulement de validation.

Quand le prototype atteint ses limites

Encourager le prototypage ne signifie pas encourager l'illusion. Un outil bricolé avec des assistants IA a des limites structurelles qu'il faut identifier tôt.

La sécurité est le premier angle mort. Un script généré par ChatGPT ne gère pas les injections SQL, ne chiffre pas les données sensibles et ne respecte pas le RGPD par défaut. Si le prototype manipule des données clients, des informations de facturation ou des données de santé, il représente un risque juridique et technique réel. Ce n'est pas théorique : la CNIL sanctionne régulièrement des PME pour des manquements sur des outils internes.

La montée en charge est le second. Un prototype qui fonctionne pour 3 utilisateurs et 200 lignes de données ne survivra pas à 50 utilisateurs et 50 000 lignes. Les choix d'architecture (base de données, gestion des sessions, mise en cache) n'existent tout simplement pas dans un outil no-code ou un script IA.

La maintenabilité est le troisième. Un code généré par IA sans structure ni documentation devient opaque en quelques semaines. Même son créateur ne comprend plus pourquoi telle condition existe.

Le prototype est un excellent point de départ. Il n'est pas un produit fini. Confondre les deux coûte cher. Mon conseil : utilisez le prototype tant qu'il sert votre réflexion, et arrêtez-vous dès qu'il sert vos clients ou vos équipes au quotidien. C'est à ce moment que la réécriture professionnelle prend le relais.

Ce que le développeur fait avec votre prototype

Quand je reçois un prototype client, je ne le "nettoie" pas. Je le lis comme une documentation vivante.

Le code lui-même a peu de valeur technique. Ce qui a de la valeur, c'est l'intention derrière chaque fonction. Pourquoi cette colonne existe-t-elle ? Pourquoi ce calcul se déclenche-t-il à ce moment précis ? Pourquoi cette notification part-elle uniquement le lundi ?

Chaque réponse à ces questions est une règle métier validée par l'usage. Dans un processus classique, ces règles émergent au compte-gouttes pendant le développement, provoquant des allers-retours, des incompréhensions et des retards. Avec un prototype, elles sont déjà là, incarnées dans un outil qui fonctionne.

Le processus de réécriture professionnelle suit alors une logique claire :

• Extraction des règles métier : chaque comportement du prototype est documenté et validé avec le client
• Architecture adaptée : choix techniques dimensionnés pour la charge réelle et la croissance prévisible
• Couche de sécurité : authentification, chiffrement, gestion des droits, conformité RGPD
• Tests automatisés : chaque règle métier extraite du prototype devient un test vérifiable

C'est une logique qui prend tout son sens dans le développement d'un outil métier sur mesure, où chaque fonctionnalité est conçue pour répondre à un besoin précis, déjà validé par le terrain.

Résultat concret : le projet démarre avec une longueur d'avance. Les phases de cadrage et de spécification, qui représentent habituellement 20 à 30 % du budget total d'un projet informatique, sont considérablement réduites. Le prototype a déjà fait le travail.

Comment prototyper intelligemment avant de passer la main

Si vous envisagez de construire un outil interne avant de le confier à un développeur, quelques principes simples maximiseront la valeur de votre prototype.

Concentrez-vous sur le parcours principal. Ne tentez pas de couvrir tous les cas de figure. Modélisez le flux que vous utilisez le plus souvent, celui qui représente 80 % de votre activité quotidienne. Les exceptions viendront plus tard.

Notez vos frustrations en cours de route. Chaque moment où vous pensez "ce serait mieux si..." est une spécification fonctionnelle. Tenez un journal simple des limitations que vous rencontrez. Cette liste vaut de l'or pour le développeur qui reprendra le projet.

Ne stockez pas de données sensibles dans le prototype. Utilisez des données fictives ou anonymisées. La conformité réglementaire n'est pas un détail qu'on ajoute à la fin. C'est une contrainte qui structure l'architecture dès le départ.

Acceptez l'imperfection. Le prototype n'a pas besoin d'être joli ni performant. Il doit être honnête : refléter votre façon réelle de travailler, sans chercher à impressionner le prestataire qui le recevra.

Cette approche rejoint d'ailleurs une logique plus large. À budget égal, un projet bien cadré en amont permet d'atteindre un niveau de qualité supérieur, simplement parce que le temps n'est pas gaspillé à deviner ce que le client veut vraiment.

Les limites de cette approche : quand le prototype ne suffit pas

Il serait malhonnête de présenter le prototypage client comme une solution universelle. Certains projets ne s'y prêtent pas.

Quand le besoin est collectif et transverse (un ERP, un CRM multi-équipes), le prototype d'un seul utilisateur ne capture qu'une fraction du problème. Les interactions entre services, les droits d'accès différenciés, les workflows d'approbation : tout cela dépasse ce qu'un dirigeant peut modéliser seul avec un outil no-code.

Quand le projet implique des intégrations complexes avec des systèmes existants (comptabilité, logistique, API tierces), le prototype ne peut pas simuler ces connexions de manière fiable. Le risque est de construire un modèle mental du système qui ne correspond pas à la réalité technique des échanges de données.

Quand le volume de données ou le nombre d'utilisateurs simultanés est élevé dès le lancement, le prototypage peut donner une fausse impression de simplicité. Ce qui fonctionne sur un tableur ne fonctionnera pas avec 10 000 lignes ajoutées par jour.

Dans ces cas, un travail de cadrage structuré reste indispensable. Le prototype ne remplace pas le cahier des charges : il le complète, et parfois il le rend superflu. La distinction est importante.

Le cahier des charges de demain est un outil qui fonctionne

Le cahier des charges formel ne disparaîtra pas. Il reste nécessaire pour les aspects contractuels, les engagements de délais et la définition du périmètre. Mais son rôle change.

Avant l'IA générative, le cahier des charges était le seul véhicule de transmission du besoin entre le commanditaire et le développeur. Il devait tout contenir, tout anticiper, tout décrire. C'est pour cette raison que les méthodologies de projet insistent tant sur sa rigueur : un oubli dans le document se transforme en surcoût pendant le développement.

Aujourd'hui, un dirigeant de PME peut créer en quelques jours ce qui aurait nécessité des semaines de spécification. Le prototype devient le canal principal de communication du besoin. Le cahier des charges écrit se recentre sur ce qu'il fait le mieux : formaliser les contraintes non fonctionnelles (sécurité, performance, conformité) et fixer le cadre contractuel.

Cette complémentarité entre le prototype fonctionnel et le document formel produit des projets mieux calibrés, avec moins de surprises et des budgets plus prévisibles.

Si vous avez bricolé un outil interne qui tourne, même de manière bancale : ne le cachez pas. Ne le jetez pas. Il contient la matière première la plus précieuse d'un projet de développement : votre expertise métier, encodée dans un système qui marche.

Et si vous n'avez pas encore essayé : qu'est-ce qui vous empêche de passer un week-end à prototyper l'outil dont vous rêvez depuis deux ans ?

Sources : Manager Go - Élaborer un cahier des charges Orsys Le Mag - Comment rédiger un bon cahier des charges Goodness - La bonne compréhension du cahier des charges par vos clients Codedesign - Comment rédiger un cahier des charges