Par Chahid Naoufel

Publié le · Modifié le · Vérifié le

Les points essentiels

  • Les bonnes questions rendent comparables des propositions qui utilisent des mots similaires pour des périmètres différents.
  • Demandez comment le problème, le résultat, les risques et les non-objectifs seront documentés.
  • Les références doivent prouver un rôle et une méthode, pas seulement une proximité de secteur.
  • Données, comptes, code, configurations, tests et coûts récurrents méritent une réponse écrite.
  • La sortie, la maintenance et le transfert se négocient avant le démarrage.

1. Que faites-vous exactement ?

  • Quel problème précis traitez-vous ?
  • Qu’est-ce qui reste hors périmètre ?
  • Pourquoi l’IA est-elle préférable à une règle ou un changement de processus ?
  • Quelle différence faites-vous entre démo, prototype, pilote et production ?
  • Quels livrables et critères terminent chaque phase ?
  • Quelles dépendances doivent être fournies par notre équipe ?

2. Comment la valeur sera-t-elle mesurée ?

  • Quelle référence faut-il établir avant le projet ?
  • Quel résultat métier principal suivrez-vous ?
  • Comment compterez-vous corrections et transferts ?
  • Quels seuils déclenchent extension, réduction ou arrêt ?
  • Comment isolerez-vous les autres facteurs ?
  • Quel coût par résultat accepté sera visible ?

3. Qui travaillera réellement sur le projet ?

  • Quels profils sont nommés et disponibles ?
  • Que réalisez-vous vous-même ou sous-traitez-vous ?
  • Qui prend les décisions d’architecture et de sécurité ?
  • Quelle expérience avez-vous sur ce type d’intégration ?
  • Comment gérez-vous une absence ou un départ ?
  • Qui assure le support après la mise en service ?

4. Quelles preuves pouvez-vous montrer ?

Une réponse utile décrit le contexte, le rôle exact du prestataire, les critères, les limites et ce qui fonctionne encore. Un logo sans autorisation ni interlocuteur ne constitue pas une preuve.

  • Cas anonymisé avec métriques définies.
  • Exemple de plan de test.
  • Exemple de documentation de reprise.
  • Explication d’un échec ou d’un changement de cap.
  • Référence vérifiable lorsque le client l’autorise.
  • Démonstration sur un cas nouveau, pas seulement préparé.

5. Où vont nos données et qui peut y accéder ?

  • Quelles catégories sont nécessaires ?
  • Quels fournisseurs et sous-traitants interviennent ?
  • Où ont lieu traitement, stockage et support ?
  • Les données servent-elles à améliorer un service ?
  • Quelles durées, suppressions et sauvegardes ?
  • Quels comptes, rôles et journaux sont prévus ?

6. Que posséderons-nous et pourrons-nous reprendre ?

6. Que posséderons-nous et pourrons-nous reprendre ?
ÉlémentQuestion à trancherPreuve
ComptesAu nom de qui ?Accès administrateur client
Code/configurationQuels droits et licences ?Dépôt et inventaire
Données/indexQuel format de restitution ?Export testé
Prompts/testsSont-ils transmis ?Versions accessibles
DocumentationPermet-elle la reprise ?Exercice par une autre personne
Modèles tiersQuelles restrictions ?Contrats et dépendances

7. Comment le service sera-t-il exploité ?

  • Qui reçoit les alertes ?
  • Quels délais et niveaux de support ?
  • Comment sont gérés versions et régressions ?
  • Qui maintient les sources et intégrations ?
  • Quels plafonds de coût et d’action ?
  • Comment arrêter, reprendre et informer après incident ?

8. Que comprend le prix — et la sortie ?

  • Cadrage, construction et intégration.
  • Licences, modèles et volumes inclus.
  • Tests, sécurité et documentation.
  • Formation et transfert.
  • Maintenance et changements.
  • Restitution, migration et révocation des accès.

Pourquoi ces questions font la différence avant de signer

Une proposition utilise souvent des termes larges comme audit, POC, assistant ou mise en production. Les questions transforment ces mots en responsabilités, livrables, critères et coûts comparables. Elles révèlent aussi les hypothèses que votre équipe devra fournir.

Demandez des réponses écrites pour les éléments structurants. Le document ne doit pas tout figer, mais il fournit une référence lorsque le périmètre, un fournisseur ou une contrainte change.

Distinguer POC, MVP, pilote et déploiement

Le POC vérifie une faisabilité

Il teste une hypothèse technique sur un périmètre contrôlé. Il ne prouve pas encore l’intégration, l’adoption, la sécurité ou la performance à l’échelle. Demandez la question testée et la décision produite.

Le MVP organise un premier produit utilisable

Il réunit le minimum de parcours, sources, contrôles et support permettant à un groupe défini d’accomplir une tâche. Minimum ne signifie pas absence de sécurité ou de mesure.

Le pilote mesure dans un contexte réel limité

Il implique des utilisateurs, des exemples représentatifs, une référence et des seuils. Les erreurs, transferts, coûts et retours doivent être comptés pour décider d’étendre, corriger ou arrêter.

Le déploiement ajoute l’exploitation

Identité, disponibilité, surveillance, incidents, versions, maintenance, formation et reprise deviennent des livrables. Une démonstration stable ne répond pas encore à ces exigences.

Reconnaître une expertise vérifiable

Une référence décrit le rôle exact de l’agence

Contexte, période, responsabilités, données, contraintes, résultat et état actuel rendent le cas lisible. Un logo ou un secteur proche ne démontre pas que l’équipe a réalisé l’architecture dont vous avez besoin.

Une compétence se voit dans les artefacts

Demandez un plan de test, un schéma expurgé, une procédure d’incident, une documentation de reprise ou une démonstration sur un exemple nouveau. Ces preuves montrent la méthode sans exiger de révéler les données d’un client.

Approfondir données, confidentialité et conformité

Où les données sont-elles traitées et hébergées ?

Cartographiez interface, modèle, recherche, connecteurs, mémoire, journaux, sauvegardes et support. Demandez lieux, fournisseurs, sous-traitants, accès et durées pour chaque couche, pas seulement pour le modèle principal.[1][2][3][4]

Les données servent-elles à entraîner ou améliorer un service ?

La réponse doit distinguer votre propre adaptation, l’amélioration du fournisseur et l’analyse opérationnelle. Vérifiez réglages, contrat, offres et traitements en aval au lieu de vous fier à une phrase commerciale.[1][2][3][4]

Comment RGPD et AI Act sont-ils qualifiés ?

L’agence doit identifier les rôles, les données et le type d’usage, puis associer les responsables juridiques compétents. Elle ne doit pas promettre une conformité automatique attachée à un outil ou à une certification.[1][2][3][4]

Transformer la réversibilité en exercice concret

À qui appartiennent comptes, code, données et configurations ?

Le contrat précise propriété, licences, droits d’usage, accès administrateur et formats de restitution. Les comptes structurants et la facturation devraient rester visibles et contrôlables par l’entreprise.

Que prévoit la clause de sortie ?

Définissez préavis, assistance, export, documentation, révocation, suppression, coûts et responsabilités. Une clause générale est insuffisante si aucun format ni délai n’est testable.

Comment prouver qu’une reprise est possible ?

Faites exécuter une procédure par une personne qui n’a pas construit le système : retrouver un secret, relancer un environnement, rejouer des tests, modifier une source et traiter une alerte. Les lacunes deviennent ainsi visibles avant la fin.

Vérifier autonomie, transfert et accompagnement après livraison

Ce que doit couvrir le transfert de compétences

Architecture, données, sources, droits, tests, déploiement, coûts, surveillance, incidents et changements doivent être compris par les rôles internes concernés. La formation s’appuie sur les outils réels et laisse des supports maintenables.

Qui assure le suivi en production ?

Nommez les responsables des alertes, mises à jour, fournisseurs, sources et demandes utilisateur. Précisez horaires, délais, niveaux de gravité et ce qui relève d’une évolution facturable.

Vérifier la capacité à expliciter les limites

Demandez à l’équipe d’expliquer ses limites, de documenter une hypothèse invalidée et de proposer une alternative plus simple. Traitez cette discussion comme un élément de due diligence, et non comme une garantie de collaboration réussie.

Questions fréquentes

Quelle est la première question à poser ?

Quel problème précis sera résolu, pour qui, et comment sa résolution sera-t-elle vérifiée ?

Comment vérifier une référence ?

Demandez le rôle exact, les contraintes, la méthode, les limites et une preuve ou un interlocuteur lorsque l’autorisation le permet.

Que demander sur les données ?

Catégories, finalités, fournisseurs, lieux, accès, rétention, suppression, sauvegardes, journaux et incidents.

Que signifie la réversibilité ?

La capacité contractuelle et technique à récupérer les éléments utiles, révoquer les accès et faire fonctionner ou reconstruire le service ailleurs.

Quel signal doit alerter ?

Une garantie sans accès aux données, une méthode invérifiable, des comptes hors de votre contrôle ou l’absence de plan de maintenance et de sortie.

Faut-il poser les mêmes questions à toutes les agences ?

Utilisez le même socle pour comparer, puis approfondissez selon les données, actions, risques et compétences propres au projet.

Sources

  1. AI Risk Management Framework — National Institute of Standards and Technology. Publié le . Consulté le . ↩1↩2↩3
  2. Développement des systèmes d’IA : les recommandations de la CNIL pour respecter le RGPD — CNIL. Publié le . Consulté le . ↩1↩2↩3
  3. AI Act — Commission européenne. Mis à jour le . Consulté le . ↩1↩2↩3
  4. Regulation (EU) 2024/1689 — Artificial Intelligence Act — EUR-Lex. Publié le . Mis à jour le . Consulté le . ↩1↩2↩3

Poursuivre votre lecture