Comment standardiser la livraison d’une automatisation IA à un client ?
Une automatisation client est livrée lorsque son résultat attendu, ses entrées, ses exceptions, ses coûts et son propriétaire sont documentés, pas seulement lorsqu’elle fonctionne pendant une démonstration. Le dossier minimal contient un périmètre signé, un jeu de tests, les accès détenus par le client, une procédure d’incident, un budget d’usage, une politique de données et un plan de sortie. La recette finale doit inclure une panne simulée et une reprise sans doublon avant le transfert de responsabilité.
La démonstration n’est pas la livraison
Une automatisation qui réussit devant le client peut rester impossible à exploiter. La livraison commence par des critères d’acceptation signés et se termine lorsque le client peut comprendre l’état du système, révoquer les accès, traiter un incident et changer de prestataire. Le transfert concerne le code, mais aussi les comptes, les données, les coûts et les décisions opérationnelles.
| Bloc | Contenu minimal | Preuve de recette | Propriétaire final |
|---|---|---|---|
| Périmètre | Entrées, sorties, exclusions | Scénarios acceptés | Métier |
| Accès | Comptes, rôles, révocation | Inventaire sans secret partagé | Client |
| Qualité | Tests et seuils | Rapport reproductible | Prestataire puis client |
| Exploitation | Alertes, reprise, sauvegarde | Panne simulée | Responsable nommé |
| Économie | Budgets et facturation | Alerte de dépassement | Client |
| Sortie | Export, suppression, réversibilité | Procédure testée | Client |
Le dossier PASSAGE
- Périmètre : ce que le système fait, ne fait pas et refuse.
- Accès : comptes détenus par le client et droits minimaux du prestataire.
- Scénarios : chemin normal, exceptions et tests de non-régression.
- Supervision : métriques, alertes, propriétaire et procédure d’incident.
- Arbitrages : choix techniques, coûts, fournisseurs et limites connues.
- Garantie : durée, incidents couverts, délais et changements exclus.
- Exit : export des données, révocation, suppression et remplacement.
Faire posséder les actifs critiques par le client
Les domaines, comptes cloud, dépôts, bases de données, moyens de paiement et clés de production doivent appartenir au client. Le prestataire utilise un compte nominatif ou un rôle révocable. Une clé envoyée dans un document de livraison n’est pas un transfert propre.
La provenance du code et des artefacts doit permettre de relier une version livrée à son dépôt et à sa procédure de construction. Les principes SLSA fournissent un cadre utile pour cette traçabilité.
Recetter le résultat, les limites et la panne
Le jeu de recette contient des cas normaux, des entrées invalides, un fournisseur indisponible, un dépassement de délai et une reprise. Chaque sortie importante possède une règle d’acceptation. La recette ne se limite pas au statut HTTP ou à la présence d’un texte.
Simule une coupure entre deux effets. Le redémarrage ne doit pas renvoyer un email, recréer une facture ou écraser un dossier déjà validé. Le guide sur le monitoring des workflows IA décrit les traces et clés de reprise.
Cadrer la maintenance avant la mise en production
Sépare la garantie de conformité à la maintenance évolutive. Un bug par rapport au périmètre accepté n’est pas une demande de nouvelle fonction. Définis les horaires, le canal, la gravité, le délai de réponse et le volume inclus. Documente aussi les coûts variables et le comportement lors d’un dépassement.
Recommandation selon ta situation
- P2, premier prestataire : transforme PASSAGE en checklist contractuelle et refuse la production tant que les comptes critiques ne sont pas au client.
- P3, dirigeant : demande une panne simulée, le coût mensuel complet et une procédure de sortie avant la recette.
- P4 ou P5 : limite la première livraison à un workflow simple avec support borné, plutôt qu’une promesse de disponibilité permanente.
Le test de transfert
Une personne qui n’a pas construit le système doit pouvoir identifier son état, lancer les tests, retrouver la documentation et appliquer la procédure d’incident. Si tout dépend encore de la mémoire du prestataire, la livraison n’est pas terminée.
Voir les cas d’usage pour les consultants indépendants, la fiche ClickUp, la définition de l’automatisation et la grille pour qualifier le processus avant de construire.
Limites testées et points à vérifier
Cette page repose sur les sources officielles disponibles. Aucun test terrain Meydeey n’est revendiqué lorsque le produit n’a pas encore été évalué dans un protocole reproductible.
- Un dossier complet ne compense pas un processus métier mal défini.
- La maintenance incluse doit avoir une durée, un périmètre et un délai de réponse explicites.
- Le client doit contrôler ses comptes, domaines, données et moyens de paiement critiques.
Sources officielles et méthode
Les informations instables ont été vérifiées le 18 juillet 2026 sur les pages officielles ci-dessous. Les faits publiés par un éditeur sont distingués des observations terrain et des limites qui restent à reproduire.
- Secure Software Development Framework du NIST
- Spécification SLSA sur la provenance
- AI RMF Core du NIST
- Conventions OpenTelemetry
Consulter la méthode éditoriale et les règles de vérification.
Construire une stack IA qui reste maîtrisable
Le LABO IA t’aide à choisir les modèles, cadrer les coûts et mettre en production des systèmes vérifiables sans dépendre d’un seul fournisseur.
Découvrir le programmeQuestions fréquentes
Remets le périmètre, l’architecture, les accès, les variables, les tests, les coûts, les limites, la procédure d’incident, le plan de sauvegarde et les conditions de maintenance.
Le client doit posséder les comptes, domaines, données, clés de production et moyens de paiement critiques. Le prestataire reçoit uniquement les accès nécessaires et révocables.
Définis la période de garantie, les incidents couverts, le délai de réponse, les changements facturables et la responsabilité du client avant la mise en production.