Du prompt au processus : quand l'IA quitte la fenêtre de dialogue

Dans la fenêtre de dialogue, toute erreur reste sans conséquence : on lit la réponse et on l'écarte. Un processus tourne sans spectateur – et c'est précisément ce qui distingue les deux formes.

Quand un prompt est mûr pour devenir un processus

Trois conditions, toutes en même temps :

1. Il a fonctionné trois fois de la même façon. Pas de façon voisine – de la même façon. Automatiser un prompt qu'il fallait chaque fois réajuster, c'est automatiser le réajustement, pas le travail.
2. Les entrées sont nommables. Qu'est-ce qui entre exactement, et d'où vient-il ? Si la réponse est « cela dépend », le processus n'est pas encore descriptible.
3. Une erreur serait repérable. Si un résultat faux ressemble à un résultat juste et que personne ne regarde, c'est le contrôle qui manque – pas l'automatisation.

Les quatre briques

Un processus en détail

Comme exemple, l'analyse hebdomadaire des demandes reçues – un processus qui a du sens dans presque toute entreprise.

Où l'humain reste

Deux endroits, et ils ne se négocient pas :

À l'appréciation. Savoir si un contact est sérieusement intéressé, si un texte trouve le bon ton, si un écart est un problème ou un hasard – ces jugements reposent sur des éléments qui ne figurent pas dans les données.

Pour tout ce qui a un effet vers l'extérieur. Envoi, publication, suppression, paiement. Non parce qu'un modèle en serait incapable, mais parce qu'une erreur ne s'y rattrape plus.

Ce qui tourne mal

• Pas de frein d'urgence. Tout processus a besoin d'un endroit où l'arrêter immédiatement – connu avant d'en avoir besoin.
• Pas de journal. Sans enregistrement, impossible de reconstituer ce qui s'est passé, quand et avec quelles données.
• Pas de responsable. Les processus vieillissent en silence. Sans revue trimestrielle, un processus nuit plus qu'il ne sert au bout d'un an.
• Consignes glissées. Si le processus lit du texte de source externe – courriels, formulaires, documents –, une demande formulée comme un ordre peut s'y trouver. Ce qui agit le mieux contre cela, ce sont des droits étroits.

Je voudrais transformer un prompt récurrent en processus fixe.
Examine le projet et rédige le processus.

Le prompt que j'utilise aujourd'hui à la main :
[coller le prompt]

Situation de départ :
- À quelle fréquence je le fais : [fréquence]
- D'où viennent les entrées : [source]
- Ce qu'il advient du résultat : [description]
- Ai-je dû adapter le prompt à chaque fois jusqu'ici ? [oui / non]
- Des données de source externe entrent-elles (courriels,
  formulaires) ? [oui / non]

Tâches :
1. Vérifie les trois conditions de maturité : a fonctionné trois
   fois de la même façon, entrées nommables, erreur repérable.
   Dis clairement si l'une n'est pas remplie – le processus n'est
   alors pas encore d'actualité.
2. Rédige les quatre briques : déclencheur, entrées (avec limite
   de quantité), consigne avec espaces réservés, destination.
3. Formule une condition d'arrêt et un contrôle de plausibilité
   qui empêche des résultats faux d'avoir l'air justes.
4. Nomme les endroits où un humain doit décider.
5. Nomme ce qui doit être journalisé et comment le processus
   s'arrête.

Si le projet n'est pas viable sous cette forme, dis-le clairement
et propose la version plus modeste.

Conclusion

Le passage du prompt au processus n'est pas un obstacle technique mais une question de descriptibilité. Qui peut écrire déclencheur, entrées, consigne et destination a passé la partie difficile.

Ce qui fait ensuite la différence, ce sont les parties les moins spectaculaires : condition d'arrêt, contrôle de plausibilité, journal, frein d'urgence. Elles coûtent ensemble vingt minutes et décident si un processus sert encore au bout d'un an ou nuit en silence.

Questions fréquentes