Une équipe passe du temps à retrouver des procédures, préparer des réponses ou reformuler des documents. L’IA paraît prometteuse. Mais « installer une IA » ne dit pas encore quel problème résoudre, ni comment vérifier qu’il est résolu. Le premier livrable utile est souvent une définition du travail à améliorer.
La CNIL recommande de partir d’usages identifiés et d’encadrer les pratiques autorisées. Le NIST propose, dans son cadre volontaire de gestion des risques, d’articuler gouvernance, contexte, mesure et traitement des risques. Notre proposition ci-dessous traduit cette logique en un cadrage opérationnel, à adapter à votre organisation.
Décrire une tâche observable
Choisissez une tâche suffisamment précise pour être montrée. « Améliorer la productivité » reste trop large. « Préparer un brouillon de réponse à partir de la documentation produit, puis le faire valider par un conseiller » permet déjà de définir une entrée, un résultat attendu et une responsabilité humaine.
Pour cette tâche, notez qui la réalise, à quelle fréquence et avec quels outils. Identifiez les exceptions : document absent, information contradictoire, dossier sensible, langue différente. Une démonstration préparée uniquement avec des cas faciles renseigne peu sur le travail réel.
Définir les données autorisées
Avant de connecter un dossier partagé, établissez une liste des sources nécessaires. Pour chacune, précisez le propriétaire, les personnes autorisées à la consulter, la fréquence de mise à jour et les informations à exclure.
Une copie de démonstration peut utiliser des exemples fictifs clairement identifiés. Le passage aux données réelles demande une décision distincte. La présence d’un document dans un outil de l’entreprise ne signifie pas qu’il doit être transmis à chaque prestataire ou rendu accessible à chaque salarié.
Construire un petit jeu d’évaluation
Préparez des cas représentatifs avant de choisir définitivement le modèle. Chaque cas décrit une demande, les sources accessibles et ce qui constituerait une réponse acceptable. Ajoutez des situations où le système doit reconnaître une information manquante ou refuser une action non autorisée.
Mesurez ensuite plusieurs dimensions : exactitude, qualité des sources, temps de vérification humaine, délai de réponse et coût d’usage. Un résultat agréable à lire peut demander plus de corrections qu’un brouillon sobre. C’est le travail complet qui compte, jusqu’à la validation et l’utilisation du résultat.
Séparer le prototype de l’exploitation
Un prototype répond à une question : la solution peut-elle aider sur ce périmètre ? Un service exploité doit aussi gérer les comptes, les autorisations, les erreurs, les sauvegardes et les évolutions des modèles.
Le budget doit donc distinguer conception, intégration, calcul, hébergement et maintenance. Pour comparer deux propositions, demandez ce qui est livré, ce qui reste à votre charge et ce qui se passe si le volume d’usage augmente. Les repères tarifaires du studio exposent cette distinction entre prestation initiale et coûts complémentaires.
Prévoir une décision de poursuite
Définissez à l’avance les conditions pour poursuivre, modifier ou arrêter le projet. Par exemple : les réponses sont-elles suffisamment étayées pour le cas étudié ? Le temps de contrôle reste-t-il compatible avec le bénéfice attendu ? Les utilisateurs savent-ils quand ne pas employer l’outil ?
Cette décision évite de transformer chaque prototype en obligation de déploiement. Un essai peut révéler qu’une meilleure recherche documentaire ou une automatisation classique répond au besoin plus simplement.
Les éléments à préparer pour un premier échange
Rassemblez une description de la tâche, quelques exemples non sensibles, les outils concernés, les rôles des utilisateurs et les contraintes connues. Indiquez aussi les résultats que vous souhaitez observer. Il n’est pas nécessaire de transmettre un accès administrateur ni une base de données complète pour discuter du périmètre.
Vous pouvez présenter votre projet au studio avec ces premiers éléments. L’objectif du cadrage est de construire une décision informée, pas d’acheter une technologie avant d’avoir formulé le besoin.
