Un client est venu nous voir avec une idée vague mais séduisante – une nouvelle interface de gestion pour sa communauté en ligne. Pas d’exigences claires, pas de specs de design, juste le sentiment que son ancien site ne faisait plus l’affaire. À la fin de la journée, on avait construit un prototype fonctionnel sur Payload CMS, déployé sur une URL en ligne, et le client avait quelque chose de concret sur quoi réagir. Le tout en une seule journée de travail.
C’est pas un coup de chance. C’est un workflow reproductible. Et en Suisse, où les heures de développement senior coûtent cher et où les attentes des parties prenantes sont élevées, l’intérêt de valider vite avant d’engager un budget est difficile à contester.
La vraie question, c’est pas de savoir si ton idée est bonne. C’est de savoir si elle fonctionne dans ton environnement – et tu peux le découvrir en une journée.
Ce qu’est vraiment une preuve de concept (PoC)
Une preuve de concept (PoC), c’est une version minimale et fonctionnelle qui a une seule mission : répondre à une question précise sur la faisabilité technique. Est-ce que ça peut vraiment marcher dans notre environnement, avec nos données, connecté à nos systèmes ?
Le projet Payload CMS en est un bon exemple. La question du PoC n’était pas « est-ce que ça va être beau ? », mais : « Peut-on mettre en place une interface de gestion de contenu fonctionnelle basée sur leur structure existante, assez vite pour montrer quelque chose de concret au client aujourd’hui ? » C’est tout.
Chez what., un PoC réussi en une journée signifie que le flux de travail principal tourne de bout en bout, que le client peut interagir avec lui, et que tout le monde repart avec un signal clair : on continue ou on arrête. La barre, c’est pas un code parfait ni une sécurité niveau production. C’est juste assez pour savoir si l’idée mérite plus d’investissement.
Pourquoi l’IA rend désormais possible un délai d’une journée
Il y a deux ans, un prototype réalisé le jour même pour quelque chose comme une interface CMS personnalisée aurait été irréaliste. Tu aurais passé la matinée à discuter des exigences, l’après-midi à te battre avec du code standard, et les trois jours suivants à écrire des tests et corriger des bugs évidents.
L’IA change ça de plusieurs façons concrètes. Le plus grand gain de temps n’est pas là où la plupart des gens s’y attendent. C’est pas la génération de code en elle-même – c’est la possibilité d’utiliser un site web ou un système de design existant comme point de départ direct. On a importé l’ancien site du client dans Claude, on s’en est servi pour structurer l’architecture dans Payload CMS, et on a itéré à partir de là. Pas de fichier vierge. Pas de devinettes sur la structure du contenu.
Le deuxième avantage, c’est que l’IA te permet de sauter l’étape des tests complets pendant la phase de prototypage, sans pour autant avancer à l’aveuglette. Tu itères vite, tu vérifies manuellement les flux principaux, tu utilises des outils d’IA pour détecter les régressions au fur et à mesure. C’est pas comme ça qu’on construit un logiciel de production – mais pour un PoC, c’est exactement ce qu’il faut.
À noter : beaucoup de « problèmes d’IA » que les clients nous soumettent s’avèrent être des problèmes d’intégration une fois qu’on creuse. Un PoC d’une journée met rapidement en évidence cette distinction. Si le prototype tombe en panne parce que deux systèmes n’arrivent pas à communiquer, c’est un problème d’intégration d’outils, pas un problème d’IA – et le savoir dès le premier jour évite des semaines d’efforts mal orientés.
Autre point important : si tes workflows sous-jacents sont défaillants, même un PoC réussi ne les réparera pas. Lis notre avis sur la correction des processus avant de te lancer dans l’IA.
Le guide du PoC en une journée
Voici comment se déroule concrètement une journée type.
Matin : découverte et cadrage (1–2 heures)
L’étape la plus importante – et celle que la plupart des équipes veulent sauter. Avant de commencer quoi que ce soit, on s’assoit avec le client et on identifie la seule question à laquelle le PoC doit répondre. On établit aussi ce qu’on ne va explicitement pas développer aujourd’hui : les flux d’authentification, la gestion des erreurs, la réactivité mobile, les autorisations d’administration. Tout ce qui ne fait pas partie de la boucle principale est mis de côté.
Les données d’entrée sont très importantes ici. Le scénario idéal, c’est un site web existant, un système de design, ou même un guide de marque bien structuré. Ça donne à l’IA une base concrète sur laquelle travailler, plutôt que de partir de rien.
Midi : développement et déploiement (3–4 heures)
Une fois le périmètre défini, on décompose le prototype en tâches aussi petites que possible. C’est essentiel – pas parce que c’est plus propre, mais parce que les outils d’IA produisent des résultats nettement meilleurs quand ils travaillent sur des problèmes ciblés et bien délimités plutôt que sur des consignes vagues. Chaque tâche est mise en œuvre, vérifiée et itérée avant de passer à la suivante.
Nos outils de prédilection pour ce type de travail : Claude Code pour l’implémentation et Claude pour les décisions d’architecture. Pour le déploiement, on lance un simple droplet Digital Ocean – rien d’extraordinaire, juste assez pour le rendre accessible et partageable. Le client reçoit une vraie URL, pas une démo locale qui ne fonctionne que sur notre ordinateur.
Fin d’après-midi : itération et remise (1–2 heures)
On passe en revue les principaux workflows avec le client, on corrige les problèmes évidents qui remontent et on documente ce qui est inclus ou non dans le périmètre. La remise, c’est pas juste une URL – c’est une vision claire de ce que le PoC a prouvé, de ce qu’il n’a pas prouvé, et de ce à quoi ressemblerait le prochain sprint.
La plus grande erreur que font les clients avant un PoC, c'est de le traiter comme un cahier des charges. Un PoC a besoin d'une question, pas de dix fonctionnalités – plus le périmètre est restreint, plus le résultat est utile.
Qu’est-ce qui fait un bon candidat pour un PoC d’une journée ?
Toutes les idées ne se prêtent pas à ce format. Celles qui fonctionnent bien partagent quelques caractéristiques :
- Un périmètre restreint avec des entrées et des sorties claires
- Au moins quelques éléments existants sur lesquels s’appuyer (ancien site, système de design, exemples de données)
- Des fonctionnalités de base largement standard – gestion de contenu, traitement de formulaires, affichage de données simple
- Aucune dépendance stricte vis-à-vis d’intégrations tierces complexes dès le premier jour
Les mauvais candidats, ce sont tous ceux qui nécessitent une intégration profonde de systèmes hérités, une validation de conformité ou des flux de données entre plusieurs systèmes avant même que le concept de base puisse être testé. Ceux-là ont d’abord besoin d’un sprint de cadrage en bonne et due forme, pas d’une construction en une journée.
| Bons candidats pour un PoC | Mauvais candidats pour un PoC |
|---|---|
| Outil interne de questions-réponses sur les connaissances | Intégrations ERP héritées complexes |
| Démonstration de chat pour le service client | Validation de conformité multi-juridictionnelle |
| Extraction de données de facturation | Flux de données multi-systèmes dès le premier jour |
| Résumés de rapports générés par l’IA | Tout ce qui nécessite une migration préalable des données |
Valide rapidement, investis intelligemment
Les entreprises qui gaspillent de l’argent dans la transformation IA ne choisissent généralement pas les mauvaises idées. Elles engagent l’intégralité de leur budget de développement avant de valider l’hypothèse de base. Un PoC IA d’une journée existe précisément pour éviter cette erreur.
Passer une semaine sur une hypothèse non validée coûte cher. Un après-midi, non.
L’alternative – mener un cycle de développement complet assisté par l’IA avant de tester si la solution fonctionne réellement dans ton environnement – est l’un des schémas les plus récurrents qu’on observe dans les projets d’IA qui échouent. On en parle plus en détail dans l’article « 5 erreurs que tu fais probablement dans ta transformation IA ».
Si tu as une idée en tête et que tu n’es pas sûr qu’elle vaille la peine d’être développée, c’est exactement la conversation à avoir. Notre équipe d’automatisation IA travaille avec les entreprises pour définir le périmètre, développer et valider rapidement – afin que tu investisses dans ce qui fonctionne, et non dans ce qui semble prometteur sur le papier.
