Prototyper un assistant métier avec Gemini API, sans perdre le contrôle

Un assistant métier ne commence pas par une connexion à toutes les données de l'entreprise. Il commence par une tâche bornée, des exemples attendus et une règle claire pour les situations où le système ne doit pas répondre. Gemini API fournit des briques ; l'application conserve la responsabilité des données, décisions et actions.

Assistant, outil ou agent : trois périmètres

Un assistant produit du contenu pour une personne. Un outil expose une fonction définie, par exemple rechercher une fiche. Un agent enchaîne des étapes et peut choisir d'appeler des outils. Le risque change lorsque le système passe d'une proposition à une action sur un logiciel métier.

1. Écrire le contrat du prototype

Le contrat précise les utilisateurs, la tâche autorisée, les données acceptées, le format de sortie, les refus attendus et la procédure de recours. Il nomme aussi ce qui reste hors périmètre. Un assistant qui prépare un brouillon n'a pas les mêmes droits qu'un système qui déclenche une action.

2. Écrire des instructions testables

La documentation Google recommande des instructions claires, du contexte pertinent et, lorsque c'est utile, des exemples. Ces éléments doivent être versionnés avec le jeu de tests : une modification du prompt peut corriger un cas et en dégrader un autre.

• Indiquer la tâche et le format attendu.
• Préciser les informations que l'assistant ne doit pas inventer.
• Fournir des exemples représentatifs, y compris des refus attendus.
• Demander au système de signaler une information absente plutôt que de la compléter.

3. Contraindre la forme avec une sortie structurée

Gemini API peut produire une sortie conforme à un schéma défini. Cela facilite la validation technique des champs, types et valeurs attendues. Une structure valide ne garantit pourtant pas que le contenu est exact : l'application doit encore contrôler les références, règles métier et informations absentes.

4. Construire un jeu d’évaluation

Le jeu d'évaluation contient des demandes normales, ambiguës, incomplètes et adverses. Pour chaque exemple, classez la réponse : correcte, incomplète, inventée, hors format, refus injustifié ou action non autorisée. La sécurité dépend de l'application complète : modèle, prompt, filtres, droits, interface, journaux et contrôle humain.

5. Ajouter des outils en lecture seule

Le function calling permet au modèle de proposer un appel d'outil ; l'application décide de l'exécuter et lui retourne le résultat. Commencez par une recherche ou une lecture bornée. Limitez les droits au strict nécessaire, validez tous les paramètres et exigez une confirmation humaine avant une action qui modifie un système.

6. Minimiser les journaux

Les journaux aident à diagnostiquer les erreurs, mais peuvent aussi recopier prompts, réponses, identifiants ou documents. Consignez un identifiant de test, la version du modèle, le statut et les erreurs utiles ; évitez les contenus personnels ou secrets qui ne sont pas nécessaires au diagnostic. Vérifiez la politique de journaux et les conditions applicables au service.

7. Déployer par paliers

• Prototype isolé sur données fictives ou non sensibles.
• Pilote limité à quelques utilisateurs et outils en lecture seule.
• Revue des erreurs, accès, journaux et procédure de repli.
• Extension seulement après décision documentée et contrôle maintenu.

8. Choisir une version de modèle explicitement

La liste des modèles et leurs capacités évoluent. Épinglez un identifiant adapté lorsque l'API le permet, testez toute migration sur le même jeu d'évaluation et consignez la date du changement. Une amélioration générale annoncée par un fournisseur ne prouve pas une amélioration sur votre tâche.

Mesurer sans extrapoler

Consignez les réponses acceptées, corrigées et refusées sur un échantillon défini. Si vous mesurez un temps de traitement, publiez le protocole et conservez le temps de contrôle humain. Un prototype fonctionnel ne prouve pas un gain en production.

Sources officielles

Google AI for Developers — Prompt design strategies

Google AI for Developers — Structured output

Google AI for Developers — Function calling

Google AI for Developers — Safety guidance

Google AI for Developers — Modèles Gemini

Google AI for Developers — Politique des journaux

ANSSI — Recommandations de sécurité pour un système d'IA générative

CNIL — Questions-réponses sur l'utilisation d'un système d'IA générative