Du prototype à l’exploitation : les points à clarifier avant un usage réel

Le premier utilisateur change la tâche

Un prototype demande si une idée est techniquement possible, compréhensible ou intéressante. Dès qu’une organisation l’utilise régulièrement, d’autres attentes apparaissent : préserver les données, avoir un interlocuteur en cas d’erreur et éviter les interruptions imprévues lors des changements.

Il ne s’agit pas d’imposer une grande organisation d’exploitation à chaque prototype. La préparation doit correspondre à l’usage. Site d’information, outil de notes interne et application de restauration scolaire ont des exigences différentes, qui doivent être explicites.

Ces questions proposent une discussion avant l’usage réel. Elles ne remplacent pas l’examen de l’application concrète.

1. Quel processus doit fonctionner ?

« L’application est accessible » est un objectif faible si sa fonction essentielle est inutilisable. Pour une commande, une personne autorisée peut-elle la terminer dans le délai prévu ? Pour un service d’information, les bonnes données sont-elles faciles à trouver et à comprendre ?

Les attentes découlent du processus : quelle fraîcheur des données, quelle interruption acceptable et quelle erreur perceptible ? Le SRE Workbook de Google présente un exemple de document d’objectifs de servicepour expliciter objectifs et mesures. Le principe s’applique aussi aux petites applications ; les valeurs doivent correspondre au besoin.

2. Qui assume quelle responsabilité ?

Le suivi technique n’est qu’une partie. Il faut aussi répondre aux questions métier, accorder les accès et décider des changements. Une même personne peut cumuler plusieurs rôles, qui doivent néanmoins être nommés.

Une courte fiche de contact est souvent plus utile qu’une documentation sans responsable : qui joindre, où signaler les problèmes, quelles informations donner et qui prend le relais en cas d’absence ?

3. Comment repère-t-on une erreur ?

Un serveur peut fonctionner tandis qu’un processus métier échoue. La surveillance doit donc suivre le parcours important. Erreurs techniques, retours utilisateurs et contrôles des fonctions centrales se complètent.

L’objectif n’est pas de multiplier les notifications. Une alerte doit permettre une réaction concrète. Si personne ne sait quoi faire, la conception de l’exploitation est incomplète.

4. Que deviennent les données ?

Une sauvegarde est d’abord une copie stockée. Son utilité se démontre à la restauration : quelles données contient-elle, quelles modifications peut-on perdre entre deux copies, quels accès et outils faut-il pour restaurer ?

Ces questions font partie de la conception, comme la transmission sûre ou la suppression en fin de collaboration. Un export lisible peut être plus utile qu’une fonction de confort supplémentaire.

5. Comment déploie-t-on les modifications ?

Une nouvelle version modifie un système en fonctionnement. Il faut tracer la version utilisée et ses vérifications. Les changements de données exigent une attention particulière : réinstaller un ancien programme n’annule pas automatiquement une migration.

Un processus simple et documenté peut suffire pour un petit service. L’essentiel est de ne pas réfléchir pour la première fois à un changement raté sous pression. La présentation de Google des Production Readiness Reviews inscrit ces questions dans une prise de responsabilité opérationnelle plus large.

6. Qu’est-ce qui n’est pas encore couvert ?

Un lancement limité peut être pertinent. Il faut préciser public, fonctions et accompagnement. Une limite explicite se traite ensemble ; une attente tacite n’apparaît souvent qu’en cas de problème.

Schulmittag illustre dans mon répertoire le lien entre produit et exploitation continue. Schulnavi montre un autre aspect : la responsabilité de l’origine et de la clarté des données. La question commune reste ce que les personnes peuvent réellement attendre d’un système.