8 min de lecture - Sprint de découverte IA de 2 semaines pour fondateurs non-tech

Quand on est fondateur ou fondatrice en dehors du monde tech, l'injonction à « faire quelque chose avec l'IA » peut vite ressembler à un piège.

Vous pouvez passer des semaines à comparer des outils, accumuler dix démonstrations, et rester sans réponse à la seule question qui compte vraiment : quel workflow changeons-nous, et comment saurons-nous que cela fonctionne ?

C'est pourquoi un sprint de découverte est utile. Il impose de la concentration. Deux semaines, c'est suffisamment long pour valider la faisabilité, et suffisamment court pour éviter de construire la mauvaise solution.

Ce que vous allez apprendre

• Comment choisir un workflow « adapté à l'IA » (et éviter ceux qui ne le sont pas)
• Qui doit être impliqué pour éviter d'être bloqué plus tard par la sécurité ou les opérations
• Un programme jour par jour pour un sprint de deux semaines
• Les livrables à attendre à l'issue du sprint (mémo, backlog, risques, prochaine étape)
• Un brief de découverte prêt à copier-coller, à utiliser avec votre équipe ou un consultant

L'essentiel

Un sprint de découverte IA de deux semaines aide les fondateurs non techniques à éviter la course aux outils, en imposant dès le départ un workflow clair, un périmètre de données défini et des indicateurs de succès. En 10 jours ouvrés, vous pouvez mener une évaluation légère sur des exemples réels, cartographier les risques (sécurité, qualité, adoption), et aboutir à un backlog de livraison ainsi qu'à une décision go/no-go pour un sprint de développement.

Ce que ce sprint est (et ce qu'il n'est pas)

Ce n'est pas un hackathon, et ce n'est pas non plus un projet de sélection de prestataires déguisé en « stratégie ».

C'est un processus court et structuré, destiné à répondre aux questions suivantes :

• Quel workflow allons-nous transformer ?
• Quelles données pouvons-nous utiliser (et lesquelles sont hors limites) ?
• Comment allons-nous mesurer la qualité et les échecs ?
• Que devons-nous construire en premier ?
• Qui en est responsable après le lancement ?

Si vous pouvez répondre à ces questions, vous pouvez financer l'étape suivante en toute confiance.

Qui doit être dans la pièce (pour ne pas caler en semaine 3)

Les fondateurs essaient souvent de mener la découverte avec seulement un profil « produit + un ingénieur ». Cela fonctionne, jusqu'au jour où cela ne fonctionne plus.

Rôles minimums pour une équipe fondatrice, tous secteurs confondus :

• Responsable du workflow : la personne qui vit la douleur au quotidien et peut valider les résultats.
• Responsable des données : quelqu'un qui sait où se trouvent les données et ce qui peut être partagé.
• Contribution sécurité/conformité (même légère) : pour éviter de refaire le travail sur les limites du périmètre.
• Responsable de la livraison (interne ou externe) : pour traduire les décisions en backlog.

Si vous n'avez pas de responsable sécurité dédié, il vous faut quand même quelqu'un capable de dire « oui, cette donnée est autorisée » ou « non, cela dépasse une limite ».

Les questions d'entretien qui rendent la découverte utile

La découverte échoue lorsque tout le monde reste au niveau de la « stratégie IA ». Ce qu'il vous faut, ce sont des détails opérationnels.

Questions qui fonctionnent bien avec des équipes non techniques :

• « Montrez-moi les 10 derniers exemples de ce workflow. » (vrais tickets, vrais documents, vrais e-mails)
• « À quoi ressemble un résultat parfait ? » (format, ton, champs obligatoires)
• « Quelle serait une erreur dangereuse ? » (mauvaise politique, mauvais client, mauvais chiffre)
• « Quand ce n'est pas parfait, que font les équipes aujourd'hui ? » (étapes manuelles, circuits d'escalade)
• « Quelles données n'avons-nous absolument pas le droit de toucher ? » (données personnelles, contrats, données financières)

Si vous ne pouvez pas répondre à ces questions, vous n'avez pas encore assez de clarté pour un sprint de développement. Ce n'est pas grave : cela signifie simplement que la découverte fait son travail.

Le programme sur 2 semaines (10 jours ouvrés)

Utilisez ce programme comme guide jour par jour. Adaptez-le, mais respectez le délai imparti (timebox).

Jours 1-2 : choisir le workflow et définir le « bon » résultat

• Choisissez un workflow à la valeur claire (réponses au support, traitement de documents entrants, recherche interne).
• Rédigez les critères d'acceptation : ce qu'est un bon résultat et ce qui est inacceptable.
• Choisissez l'indicateur (temps de cycle, taux de déflexion, taux d'erreur, délai de décision).

Jours 3-4 : cartographier le périmètre des données

• Recensez les sources de données et leur fréquence de mise à jour.
• Identifiez les catégories sensibles (données personnelles, données clients, documents réglementés).
• Décidez ce qui peut être journalisé et conservé.

Jours 5-7 : constituer un petit jeu d'évaluation

• Rassemblez 30 à 100 exemples réels (ou des équivalents synthétiques si nécessaire).
• Notez ce à quoi ressemble un « bon » résultat (grille de notation ou labels).
• Définissez un seuil minimal pour déployer un pilote.

Jours 8-9 : esquisser le premier sprint de développement

• Choisissez une direction d'architecture (souvent le RAG en priorité pour les problématiques de connaissance).
• Créez le backlog du sprint de développement de deux semaines.
• Identifiez les dépendances et les décisions à prendre (accès, outils, responsables).

Jour 10 : go/no-go et prochaine étape

• Présentez les conclusions et les risques.
• Décidez : sprint de développement, découverte complémentaire, ou arrêt.
• Désignez un responsable et une date pour le prochain point d'étape.

Que faire face à des résultats « peut-être » (la voie honnête)

Tous les sprints ne se terminent pas par un « oui, construisons-le ». Parfois, vous découvrez que :

• les données sont encore trop désordonnées
• le workflow a de la valeur, mais la surface d'intégration est trop importante
• la qualité est atteignable, mais uniquement avec un périmètre plus restreint

Cela reste un succès si vous pouvez formuler clairement la prochaine action :

• restreindre le workflow (rédaction de brouillons uniquement, plutôt qu'une automatisation complète)
• corriger un problème de données en amont avant de construire
• mener une seconde découverte centrée sur les droits d'accès et la conformité

L'erreur coûteuse consiste à faire comme si vous aviez obtenu un feu vert, alors que vous n'avez en réalité qu'une incertitude.

Ce que vous devez obtenir à la fin (les livrables)

Un sprint de découverte est réussi s'il produit des livrables réutilisables :

• Un mémo de décision d'une page (workflow, périmètre, approche, risques)
• Un backlog priorisé pour le sprint 1 et le sprint 2
• Un plan d'évaluation léger (jeu de référence + seuils)
• Un registre des risques (sécurité, adoption, fiabilité) avec des responsables identifiés

La restitution du jour 10 (courte et tranchée)

Les fondateurs terminent souvent la découverte par une réunion floue. Évitez cette erreur : terminez par une restitution claire qui rend la prochaine étape évidente.

Une structure simple :

• Ce que nous avons appris (workflow, contraintes, faisabilité)
• Ce que nous avons construit ou testé (référence d'évaluation, exemples de résultats)
• Les risques identifiés (et la plus grande inconnue)
• Recommandation : sprint de développement / découverte complémentaire / arrêt
• Si développement : un backlog de deux semaines et les responsables pour chaque décision

Si le sprint ne débouche pas sur une recommandation exploitable, ce n'était pas de la découverte. C'était une simple conversation.

À copier-coller : le modèle de brief de découverte

Utilisez ce brief avec votre équipe interne ou un consultant. Il garde le sprint ancré dans le concret.

Business context (2-3 sentences):
Workflow to improve:
Who uses it today:
What “good” looks like:

Constraints:
- Data that must never leave:
- Compliance requirements:
- Latency expectations:
- Budget/timebox:

Data sources:
- Source 1:
- Source 2:
- Update frequency:
- Access control model:

Evaluation:
- Example set owner:
- Scoring approach:
- Ship threshold:

Decision checkpoint:
- Who decides:
- By when:

Si vous pilotez le sprint, le script de point hebdomadaire est simple : ce que nous avons appris, ce que nous avons livré (le cas échéant), ce qui est bloqué, et quelle décision nous attendons.

Pièges courants (et comment les éviter)

• Commencer par l'outil. Remède : partez du workflow et de l'indicateur, puis choisissez l'outillage.
• Aucun responsable des données dans la pièce. Remède : désignez une personne responsable des décisions d'accès aux données.
• Aucun seuil défini pour le « bon ». Remède : créez un petit jeu d'évaluation et mettez-vous d'accord sur la qualité minimale.
• Traiter la découverte comme de la livraison. Remède : restez court et livrez un backlog, pas un produit.

Pour les chantiers sensibles en matière de cybersécurité, ajoutez une modélisation des menaces, une gestion des secrets et une revue des risques fournisseurs avant de passer à l'échelle.

Une découverte qui produit des décisions, pas des réunions

Un sprint de découverte fonctionne lorsqu'il est court, tranché et centré sur des livrables concrets. Au bout de deux semaines, vous devez disposer d'un mémo de décision, d'un plan d'évaluation et d'un backlog finançable. Si ce n'est pas le cas, vous n'avez pas mené une découverte — vous avez enchaîné des réunions.

Le vrai gain, c'est la clarté : ce que vous construisez, ce que vous ne construisez pas, et les conditions à réunir pour que le projet passe à l'échelle en toute sécurité. Besoin d'aide pour mener un sprint de découverte ? Parlons-en.