Cadrage projet IA : 15 questions avant le POC

80% des POC IA ne passent jamais en production. Ce chiffre, issu d'études Gartner et de notre expérience terrain, révèle un problème systémique : la plupart des projets IA échouent non pas pour des raisons techniques, mais par manque de cadrage initial. Ces 15 questions constituent la checklist que j'utilise avec mes clients avant de lancer tout projet IA — elles vous éviteront de gaspiller temps et argent sur un POC sans avenir.

Pourquoi le cadrage est-il si crucial ?

Un POC (Proof of Concept) coûte typiquement entre EUR 10'000 et 30'000 et mobilise vos équipes pendant plusieurs semaines. Ce n'est pas un investissement anodin. Pourtant, beaucoup d'entreprises se lancent tête baissée, séduites par la promesse de l'IA, sans avoir répondu aux questions fondamentales.

Les symptômes d'un mauvais cadrage :

• Le POC "fonctionne" mais personne ne sait quoi en faire ensuite
• Les utilisateurs finaux n'ont pas été consultés et rejettent la solution
• Les données nécessaires n'existent pas ou sont inaccessibles
• Pas de budget prévu pour passer en production
• Aucun critère de succès défini — impossible de dire si le POC est réussi ou non

Pour le dirigeant : un bon cadrage, c'est 2-3 jours de travail en amont qui peuvent vous faire économiser 3 mois de projet mal orienté. C'est l'investissement le plus rentable que vous puissiez faire.

Objectifs & Valeur métier

Ces quatre premières questions sont les plus importantes. Si vous ne pouvez pas y répondre clairement, arrêtez-vous là : le projet n'est pas mûr.

1. Quel problème métier résolvons-nous ?

Mauvaise réponse : "On veut utiliser l'IA", "On veut être innovants", "Les concurrents le font".

Bonne réponse : "Nos équipes passent 40% de leur temps à chercher des informations dans nos 500 documents de procédures. On veut réduire ce temps de moitié."

L'IA est un moyen, pas une fin. Si vous ne pouvez pas formuler le problème sans prononcer le mot "IA", c'est que vous partez dans la mauvaise direction.

2. Quelle est la valeur attendue ?

Quantifiez l'impact en termes que votre CFO comprendra :

• Heures économisées : 20 collaborateurs × 2h/semaine × 48 semaines × EUR 80/h = EUR 153'600/an
• Erreurs évitées : coût moyen d'une erreur × fréquence annuelle
• Revenus générés : leads qualifiés supplémentaires × taux de conversion × panier moyen
• Satisfaction client : impact sur le NPS, réduction du churn

Si vous ne pouvez pas chiffrer la valeur, vous ne pourrez pas justifier l'investissement ni mesurer le succès.

3. Comment mesure-t-on le succès du POC ?

Définissez des critères GO/NO-GO objectifs avant de commencer. Exemples concrets :

• "L'IA donne une réponse correcte dans 80% des cas sur notre jeu de test de 50 questions"
• "Le temps de recherche d'information passe de 15 à 5 minutes en moyenne"
• "Les utilisateurs pilotes attribuent une note de satisfaction ≥ 7/10"

Attention : "L'équipe est satisfaite" n'est pas un critère mesurable. "8 utilisateurs sur 10 déclarent que l'outil leur fait gagner du temps" l'est.

4. Qu'est-ce qui se passe si le POC réussit ?

Question souvent négligée mais cruciale :

• Y a-t-il un budget prévu pour la mise en production ? (Généralement 3-5x le budget POC)
• Qui va maintenir la solution après le déploiement ?
• Y a-t-il un sponsor exécutif pour porter le projet en comité de direction ?

Un POC réussi sans suite prévue est un gaspillage. Mieux vaut ne pas commencer que de créer de la frustration.

Données & Technique

Ces questions techniques peuvent sembler réservées aux équipes IT, mais leurs réponses ont un impact direct sur la faisabilité et le coût du projet. En tant que dirigeant, vous devez comprendre les enjeux.

5. Avons-nous accès aux données nécessaires ?

C'est LA question qui fait échouer le plus de projets IA. L'IA a besoin de données pour fonctionner — sans données, pas d'IA.

• Quelles données sont nécessaires ? Documents, emails, bases de données, historiques ?
• Où sont-elles stockées ? SharePoint, serveur interne, logiciel métier, têtes des experts ?
• Qui peut y accéder ? Faut-il des autorisations spéciales ?
• Quel format ? PDF, Word, Excel, base de données structurée ?

Cas fréquent : "On a toute la documentation" → en réalité, elle est éparpillée dans 15 dossiers, 3 formats différents, avec des versions obsolètes mélangées aux actuelles.

6. Quelle est la qualité des données ?

La qualité de l'IA est directement liée à la qualité des données. Questions à se poser :

• Complétude : avez-vous toute l'information nécessaire ou des trous ?
• Exactitude : les données sont-elles correctes et à jour ?
• Cohérence : y a-t-il des contradictions entre différentes sources ?
• Structure : données bien organisées ou en vrac ?

Règle empirique : prévoyez 30-50% du temps du POC pour la préparation des données. C'est rarement sexy, mais c'est indispensable.

7. Y a-t-il des contraintes de confidentialité ?

Cette question est particulièrement importante en Suisse, où la nouvelle LPD (Loi sur la Protection des Données) impose des obligations strictes :

• Données personnelles : noms, emails, données clients → attention au RGPD/LPD
• Secrets d'affaires : formules, process propriétaires, stratégie
• Régulations sectorielles : données médicales (LPD santé), données financières (FINMA), etc.

Ces contraintes ne bloquent pas le projet mais orientent les choix techniques : LLM on-premise vs cloud, anonymisation, etc. Voir notre article sur la conformité RGPD/LPD.

8. Quelle est l'infrastructure disponible ?

Questions à poser à votre équipe IT :

• Cloud autorisé ? Pouvez-vous utiliser Azure, AWS, Google Cloud ? Ou tout doit rester on-premise ?
• GPU disponibles ? Pour un LLM local, il faut du matériel spécifique
• Contraintes réseau ? VPN, firewall, accès aux API externes

Point clé : un projet IA sur infrastructure contrainte (tout on-premise, pas de cloud) coûte généralement 2-3x plus cher qu'un projet avec liberté d'architecture.

Utilisateurs & Usage

Un projet IA techniquement parfait mais rejeté par les utilisateurs est un échec. Ces questions garantissent l'adoption.

9. Qui sont les utilisateurs finaux ?

Identifiez précisément vos utilisateurs cibles :

• Profil : tech-savvy ou débutants ? Habitués aux outils digitaux ?
• Nombre : 5 utilisateurs pilotes ou 500 en déploiement massif ?
• Fréquence : usage quotidien intensif ou occasionnel ?
• Motivation : sont-ils demandeurs ou va-t-on leur "imposer" l'outil ?

Conseil : impliquez 2-3 utilisateurs représentatifs dès le cadrage. Leur feedback est précieux et leur implication garantit l'adoption.

10. Comment s'intègre la solution dans leur workflow ?

L'adoption dépend fortement de l'intégration dans les habitudes de travail :

• Outil séparé : nouvelle interface à ouvrir → friction, risque de non-usage
• Intégré dans l'existant : dans Teams, Outlook, le CRM → adoption naturelle

Exemple concret : un assistant IA accessible via un bouton dans Outlook aura 5x plus d'usage que le même assistant accessible via une URL à mémoriser.

11. Quel niveau de précision est acceptable ?

Question cruciale souvent négligée. L'IA n'est pas parfaite — quel taux d'erreur est tolérable ?

• Aide à la rédaction : 10-20% d'erreurs acceptables (l'humain corrige)
• Recherche documentaire : 5-10% d'erreurs acceptables
• Conseil médical/juridique : < 1% d'erreurs, avec validation humaine systématique

Plus le niveau de précision requis est élevé, plus le projet est complexe et coûteux. Soyez réalistes sur vos attentes.

12. Qui valide les réponses de l'IA ?

Définissez le niveau de contrôle humain :

• Validation systématique : chaque réponse est relue → sécurité maximale, gains limités
• Validation par échantillonnage : 10% des réponses contrôlées → bon compromis
• Aucune validation : l'IA répond directement → gains maximaux, risque si erreur

La bonne réponse dépend du contexte. Un chatbot FAQ peut fonctionner sans validation ; un assistant juridique requiert une validation systématique.

Projet & Gouvernance

Un projet IA est avant tout un projet de transformation. Ces questions organisationnelles sont aussi importantes que les questions techniques.

13. Qui est le sponsor métier ?

Un projet porté uniquement par l'IT a peu de chances de réussir. Il vous faut un sponsor métier :

• Quelqu'un de l'opérationnel qui comprend le problème au quotidien
• Avec le pouvoir de décision pour débloquer les ressources
• Capable de mobiliser les équipes et gérer la conduite du changement

Idéal : le responsable du département qui va utiliser la solution (ex: directeur service client pour un assistant support).

14. Quel est le budget et le délai ?

Soyez réalistes sur les moyens nécessaires :

Ces fourchettes varient selon la complexité. Un assistant simple sur une FAQ = bas de fourchette. Une solution intégrée à 5 systèmes = haut de fourchette.

15. Quels sont les risques identifiés ?

Listez les risques et prévoyez des mitigations :

• Risques techniques : qualité des données insuffisante, performance de l'IA en dessous des attentes
• Risques organisationnels : résistance au changement, manque de disponibilité des experts métier
• Risques réglementaires : non-conformité RGPD/LPD, problèmes de propriété intellectuelle
• Risques projet : dépassement budget/délai, départ de personnes clés

Template de cadrage

Utilisez ce template pour structurer votre réflexion et aligner toutes les parties prenantes avant de lancer le POC :

Red flags : ne pas lancer le POC si...

Au fil des projets, j'ai identifié des signaux d'alerte qui prédisent quasi-systématiquement un échec. Si vous cochez l'une de ces cases, prenez le temps de résoudre le problème avant de vous lancer :

• ❌ Pas de problème métier clair — "On veut faire de l'IA" n'est pas un problème
• ❌ Pas de sponsor opérationnel — un projet porté uniquement par l'IT ou la direction sans relais métier
• ❌ Données inexistantes ou inaccessibles — on vous dit "on verra plus tard pour les données"
• ❌ Pas de critère de succès défini — impossible de savoir si le POC est réussi ou non
• ❌ Pas de plan pour après le POC — pas de budget production, pas de ressources maintenance
• ❌ Utilisateurs finaux non consultés — on développe sans savoir ce dont ils ont vraiment besoin
• ❌ Délai irréaliste — "On veut ça pour dans 2 semaines" pour un projet complexe

Étude de cas : un cadrage réussi

Pour illustrer l'importance du cadrage, voici un exemple concret d'une PME industrielle suisse :

Prochaines étapes

Une fois le cadrage validé par toutes les parties prenantes :

1. Préparer les données : rassembler, nettoyer, structurer la documentation
2. Définir le jeu de test : 30-50 questions représentatives avec les réponses attendues
3. Choisir l'approche technique : RAG, fine-tuning, ou combinaison (voir nos articles dédiés)
4. Lancer le POC : développement, tests, itérations
5. Évaluer et décider : GO/NO-GO basé sur les critères définis

"Un POC bien cadré, c'est 50% du travail de fait. Un POC mal cadré, c'est du temps perdu pour tout le monde — et souvent la mort du projet IA dans votre entreprise pour les 2 prochaines années."