Quel travail doit réellement être facilité ?
Commencez par une tâche observable : retrouver une information dans une documentation, préparer une synthèse ou assister une équipe de développement. Décrivez les entrées, le résultat attendu et la personne qui le valide. « Mettre de l’IA à disposition » ne permet pas de choisir un modèle ni de mesurer son intérêt.
Constituez un jeu de situations représentatives, avec des cas simples, ambigus et hors périmètre. Évaluez la qualité des réponses et le temps nécessaire pour les vérifier. Prévoyez aussi le comportement attendu lorsque le modèle ne dispose pas des informations nécessaires. Une expérimentation utile compare le travail complet avec la pratique actuelle, et pas seulement la vitesse de génération.
Quelles données peuvent entrer dans le système ?
Recensez les documents, le code et les informations que les utilisateurs pourraient transmettre. Identifiez leur sensibilité, leurs propriétaires et leurs règles d’accès. Si la plateforme recherche dans des sources internes, elle doit respecter les droits de consultation de chaque utilisateur. Un document accessible au moteur ne doit pas devenir accessible à toute l’entreprise par une réponse générée.
Examinez également les traces : requêtes, réponses, journaux techniques et éventuels retours utilisateurs. Décidez ce qui est conservé, pour quelle raison et qui peut le consulter. Utilisez des données adaptées aux essais. L’hébergement interne ne suffit pas à maîtriser les informations si les intégrations, les exports ou les outils de supervision les diffusent ailleurs.
Où héberger et comment exploiter la plateforme ?
Le choix d’hébergement dépend des contraintes de données, de performance et d’exploitation. Examinez l’emplacement des traitements, les accès d’administration et les communications vers des services externes. Vérifiez les besoins matériels avec le modèle et les usages envisagés : la taille des requêtes et le nombre de sollicitations simultanées influencent le dimensionnement.
Désignez ensuite qui supervise la plateforme, applique les mises à jour et traite les incidents. Prévoyez un environnement de validation avant de changer de modèle ou de configuration. Un modèle plus récent peut répondre différemment sur les mêmes tâches. La plateforme LLM doit donc être pensée comme un service à maintenir, avec des critères d’acceptation et des responsabilités connues.
Quel coût complet pour quel usage ?
Le budget inclut les ressources de calcul, le stockage, l’intégration et le travail d’exploitation. Ajoutez le temps consacré à préparer les sources, accompagner les équipes et évaluer les réponses. Selon l’architecture retenue, certains coûts restent présents même lorsque le service est peu utilisé. Il faut les rapprocher d’un usage réel, pas d’un nombre théorique de comptes ouverts.
Pendant le pilote, suivez les tâches effectivement terminées, les réponses abandonnées et les reprises manuelles. Par exemple, une synthèse rapide mais longue à corriger peut déplacer le travail sans le réduire. Documentez les hypothèses de fréquentation et de disponibilité afin de comparer des scénarios cohérents. Élargissez ensuite l’accès à partir des résultats observés.
Qui décide des règles et de leurs évolutions ?
La gouvernance précise les usages autorisés, les données exclues et les validations humaines attendues. Elle attribue un responsable aux modèles, aux intégrations et aux sources documentaires. Elle prévoit aussi comment signaler une réponse problématique et retirer un accès ou une source devenue inadaptée. Ces règles doivent être compréhensibles par les utilisateurs dans leur travail quotidien.
Présentez clairement les limites du service : une réponse plausible peut être incorrecte et doit être vérifiée selon son impact. Organisez une revue des usages et des incidents pour ajuster le dispositif. Les choix de souveraineté se traduisent alors en décisions concrètes sur les données, les accès et l’exploitation, plutôt qu’en une simple étiquette associée à l’hébergement.