Agence d'automatisation · Livraison
Développement d'automatisation et passation client
Menez une automatisation client du contrat de prestation signé à une passation acceptée, sans développer à l'aveugle ni passer en production après un seul test réussi. Le client donne les accès et accepte le résultat via un lien public, et rien ne part en production avant l'approbation de l'architecte solutions.
- Durée: 3 à 5 semaines
- Fréquence: Pour chaque projet d'automatisation client
- Étapes: 12 étapes
- Agents IA: 2 agents IA
- Approbations: 2 approbations
Plan gratuit, sans carte de crédit.
Ce que ce modèle change
Sans le modèle
Les ingénieurs développent à l'aveugle jusqu'à ce que l'équipe informatique du client envoie les accès et de vrais fichiers d'exemple.
L'automatisation passe en production dès que le cas nominal fonctionne une fois.
Le fonctionnement de l'automatisation, et la façon de la mettre en pause, sont dans la tête d'un seul ingénieur.
Les conceptions de solution et les runbooks sont rédigés de zéro à chaque projet.
Avec le modèle
Le client donne les accès et partage les données d'exemple via un seul lien, et l'exécution montre ce qui manque encore.
La mise en production attend la checklist de tests complète et l'approbation de l'architecte solutions.
Chaque client reçoit un runbook vérifié et l'accepte via le lien public.
Des agents IA rédigent la conception et le runbook, et une personne de l'équipe vérifie les deux.
Le modèle, étape par étape
Chaque étape indique qui la réalise : une personne de votre équipe, un agent IA ou le client via un lien public. Une approbation garde toutes les étapes suivantes verrouillées jusqu'à ce qu'elle soit donnée.
- Réalisé par votre équipe
- Réalisé par un agent IA
- Réalisé par le client, via un lien public
Démarre quand
Le client signe le contrat de prestation. Le responsable de livraison lance une exécution avec le nom du client, le processus à automatiser et la date de mise en production visée.
- 1
Partager le lien de l'exécution et planifier la découverte
Jour 1Responsable de livraison · Équipe
Envoyez au contact client le lien public de l'exécution, pour qu'il voie quels accès et données d'exemple il vous faut, et planifiez la séance de découverte.
Checklist
- Lien public envoyé au contact client
- Séance de découverte planifiée
- Architecte et ingénieur affectés
Champs à remplir
- Nom du client (obligatoire)
- Processus à automatiser (obligatoire)
- E-mail du contact client (obligatoire)
- Date de mise en production visée (obligatoire)
- 2
Cartographier le processus actuel en séance de découverte
Semaine 1Architecte solutions · Équipe
Parcourez le processus avec le client : entrées, systèmes, volumes, exceptions connues et responsable de chaque partie. Convenez de ce que l'automatisation ne fera pas.
Checklist
- Entrées, systèmes et volumes notés
- Responsable de chaque partie nommé
- Cas hors périmètre convenus
Champs à remplir
- Notes de découverte (obligatoire)
- Exceptions que l'automatisation doit traiter (obligatoire)
- Hors périmètre
- 3
Donner les accès de test et partager les données d'exemple
Semaine 1Contact client · Lien public
Via le lien public, le client donne accès à un espace de test pour chaque système et partage un lien vers de vrais fichiers d'exemple, avec des exemples des exceptions connues.
Checklist
- Accès à l'espace de test donné
- Compte de service ou accès API créé
- Les exemples couvrent les exceptions connues
Champs à remplir
- Lien vers les fichiers d'exemple (obligatoire)
- Systèmes auxquels vous avez donné accès (obligatoire)
- Contact technique pour les questions d'accès
- 4
Rédiger la conception de la solution et les cas de test
Semaine 1Rédacteur de conception · Agent IA
Le rédacteur de conception transforme les notes de découverte et les exceptions en une première conception : déclencheur, mapping des données, gestion des erreurs, alertes et un cas de test pour le cas nominal et chaque exception.
Champs à remplir
- Brouillon de conception (obligatoire)
- Brouillon des cas de test (obligatoire)
Contrôle humain: L'architecte solutions corrige et approuve la conception à l'étape 5.
- 5
Approuver la conception avant le développement
Masqué sur le lien publicSemaine 2Architecte solutions · Équipe
Corrigez la conception et les cas de test, et testez vous-même les accès du client. S'il manque des accès ou des exemples, marquez l'exécution comme bloquée et notez ce qui manque.
Checklist
- Chaque exception a un cas de test
- Gestion des erreurs et alertes définies
- L'accès de test fonctionne
Champs à remplir
- Accès ou exemples manquants
Approbation: Le développement reste verrouillé jusqu'à ce que l'architecte solutions approuve la conception.
- 6
Développer l'automatisation dans l'espace de test
Semaines 2 à 3Ingénieur automatisation · Équipe
Développez selon la conception approuvée, avec journalisation, nouvelles tentatives sur chaque appel externe et une alerte quand une exécution de l'automatisation échoue.
Checklist
- Journalisation à chaque étape
- Nouvelles tentatives sur les appels externes
- L'alerte de panne arrive sur le canal convenu
Champs à remplir
- Notes de développement (obligatoire)
- Lien vers l'export du workflow ou le dépôt de code (obligatoire)
- 7
Jouer chaque cas de test, y compris les cas d'échec
Semaine 3Responsable des tests · Équipe
Jouez chaque cas de test de la conception approuvée sur les données d'exemple et notez ce qui a réussi et ce qui a échoué, avec un lien vers les preuves.
Checklist
- Le cas nominal passe
- Les données invalides sont rejetées et signalées
- Les doublons sont détectés
- Les nouvelles tentatives et les alertes fonctionnent
Champs à remplir
- Résultats des tests (obligatoire)
- Lien vers les preuves de test (obligatoire)
- 8
Approuver la mise en production
Semaine 4Architecte solutions · Équipe
Examinez les résultats des tests, les notes de développement et le plan de retour arrière, puis approuvez le passage en production.
Checklist
- Tous les cas de test sont passés
- Le plan de retour arrière est réaliste
- Le client connaît la date de mise en production
Champs à remplir
- Plan de retour arrière (obligatoire)
Approbation: La production, l'acceptation du client et la passation restent verrouillées jusqu'à ce que l'architecte solutions approuve la mise en production.
- 9
Rédiger le runbook
Semaine 4Rédacteur de runbook · Agent IA
Le rédacteur de runbook transforme les notes de développement, les résultats de tests et le plan de retour arrière en runbook : ce que fait l'automatisation, comment repérer une panne, comment la mettre en pause et la relancer, et qui contacter.
Champs à remplir
- Brouillon du runbook (obligatoire)
Contrôle humain: L'ingénieur automatisation confronte le runbook au développement à l'étape 10.
- 10
Passer en production et finaliser le runbook
Semaine 4Ingénieur automatisation · Équipe
Confrontez le brouillon du runbook au développement et corrigez-le, activez l'automatisation en production, surveillez les premières exécutions réelles et envoyez au client le runbook final par e-mail.
Checklist
- Le runbook correspond au développement
- Automatisation activée en production
- Premières exécutions réelles vérifiées
Champs à remplir
- Date de mise en production (obligatoire)
- Lien vers le runbook final (obligatoire)
- 11
Tester des cas réels et accepter l'automatisation
Semaine 4Contact client · Lien public
Le client vérifie des cas réels dans ses propres systèmes et lit le runbook que l'ingénieur lui a envoyé par e-mail, puis enregistre sa décision via le lien public, avec ce qu'il reste à changer s'il n'accepte pas encore.
Checklist
- Cas réels vérifiés dans vos propres systèmes
- Runbook lu
- Vous savez mettre l'automatisation en pause
Champs à remplir
- Décision (obligatoire)
- Ce qu'il reste à changer
- 12
Passer le relais et démarrer le support
Semaine 4Responsable de livraison · Équipe
Confirmez les conditions de support avec le client, planifiez le premier point de suivi et réduisez les accès de l'agence à ce dont le support a besoin.
Checklist
- Conditions de support confirmées
- Le client sait signaler une panne
- Accès de l'agence réduits aux besoins du support
Champs à remplir
- Date de début du support (obligatoire)
- Date du premier point de suivi (obligatoire)
Terminé quand
L'automatisation tourne en production, le client l'a acceptée, et son équipe dispose d'un runbook vérifié pour le jour où quelque chose tombe en panne.
Adaptez-le. Renommez les étapes, changez les responsables et ajoutez des points de checklist, des champs ou des approbations. Le modèle est un point de départ pour la façon de travailler de votre équipe.
Les agents IA de ce modèle
Un agent ne travaille que sur ses propres étapes, et une personne de votre équipe vérifie ce qu'il a fait. Tout ce qu'un agent écrit dans une application connectée attend une approbation, sauf si vous l'autorisez.
Rédacteur de conception
Transforme les notes de découverte en une première conception de la solution et un jeu de cas de test.
Ce qu'il fait
- Lit les notes de découverte et les exceptions saisies dans l'exécution
- Suit le format de conception indiqué dans les instructions de son étape
- Rédige le brouillon de conception et un cas de test par exception
- Termine son étape pour que la relecture puisse commencer
Contrôle humain: L'architecte solutions corrige et approuve la conception à l'étape 5.
Rédacteur de runbook
Transforme les notes de développement, les résultats de tests et le plan de retour arrière en un premier runbook pour le client.
Ce qu'il fait
- Lit les notes de développement, les résultats de tests et le plan de retour arrière de l'exécution
- Décrit ce que fait l'automatisation, comment repérer une panne et comment la mettre en pause
- Enregistre le brouillon du runbook dans son étape
Contrôle humain: L'ingénieur automatisation confronte le runbook au développement à l'étape 10.
Les questions auxquelles ce modèle répond
Donnez au client un runbook qui dit ce que fait l'automatisation, comment repérer une panne, comment la mettre en pause et qui contacter, et faites-le accepter. L'étape 9 rédige ce runbook à partir des notes de développement et des résultats de tests, l'étape 10 le confronte au développement et l'envoie au client par e-mail, et à l'étape 11 le client l'accepte via le lien public.
Faites dépendre la mise en production d'un jeu complet de cas de test, avec données invalides, doublons et pannes, et d'une personne nommée qui l'approuve. L'étape 7 contient la checklist de tests pour chaque cas d'échec, et l'étape 8 est un contrôle d'approbation qui garde la production verrouillée jusqu'à ce que l'architecte solutions approuve les résultats.
Demandez tous les accès et fichiers d'exemple au même endroit, avec les exceptions dont vous avez besoin d'exemples, avant le début du développement. À l'étape 3 le client donne les accès et partage des liens vers les fichiers d'exemple via le lien public, et à l'étape 5 l'architecte solutions marque l'exécution comme bloquée et note ce qui manque encore.
Un runbook décrit ce que fait l'automatisation, ce qui la déclenche, comment une panne se manifeste, comment la mettre en pause et la relancer, comment retraiter les enregistrements en échec et qui contacter. L'étape 9 rédige ces sections à partir des notes de développement, des résultats de tests et du plan de retour arrière, et l'ingénieur automatisation les corrige à l'étape 10.
Laissez l'IA transformer les notes de découverte en une première conception avec ses cas de test, et gardez la décision pour l'architecte solutions. À l'étape 4, le rédacteur de conception écrit le déclencheur, le mapping des données, la gestion des erreurs et un cas de test par exception, et à l'étape 5 l'architecte solutions la corrige et l'approuve.
Enregistrez les résultats de tests, l'approbation et l'acceptation du client dans le projet lui-même, pas dans des fils de discussion. L'étape 7 enregistre les résultats avec un lien vers les preuves, l'étape 8 l'approbation de mise en production avec nom et heure, et l'étape 11 la décision du client.
Exécutez ce workflow dans OKiDO
Configurez les étapes, les responsables et les approbations une fois, puis lancez une exécution pour chaque nouveau cas.