« En avant ! »
Une machine est censée prendre un article terminé et le rendre accessible aux lecteurs. Elle démarre, vérifie la liste des textes, met à jour les registres, compare les anciennes versions et prépare la prochaine série de tâches.
Quelle efficacité apparente !
Puis arrive le compte rendu :
Résultat : SUCCÈS. Nouveaux articles transmis pour publication : 0.
Pardon, la troupe a vraiment franchi la porte ? Ou a-t-elle passé la journée à remplir son autorisation de sortie ?
Difficile de ne pas penser au retour du Bataillon d’exploration dans le premier épisode de L’Attaque des Titans. Keith Shadis, qui le commandait alors, devait reconnaître que son expédition n’avait pas obtenu le résultat espéré.[1][2]
La scène de l’œuvre est tragique, avec des morts. Rien de comparable à la gravité d’un programme qui s’arrête. Ce qu’on tourne en dérision ici, c’est uniquement l’organisation du travail : beaucoup d’efforts, aucun article livré.
Vaincus par les formulaires avant même de voir un Titan
La mission est pourtant simple : recevoir un texte, le vérifier, le publier.
Mais avant de commencer, il faut refaire l’inventaire, mettre les registres d’accord, inspecter les anciennes publications et calculer le planning suivant.
Prise séparément, chaque étape peut se défendre. Lorsqu’elles deviennent toutes obligatoires avant la publication du moindre texte, cela donne :
Le Bataillon d’exploration manque de temps pendant sa réunion de départ.
Lors d’une exécution observée, la préparation et la sauvegarde des registres ont occupé le temps disponible avant le début du véritable traitement des articles. D’autres exécutions ont bien fait avancer la publication. Ce n’est donc pas un échec permanent : ce sont les tâches annexes qui peuvent étouffer l’objectif principal.
À l’expédition suivante, la carte a disparu
Reprendre un travail plus tard n’a rien d’anormal, à condition de savoir où l’on s’est arrêté.
Or, dans un des chemins d’exécution, certaines informations nécessaires à la reprise n’ont pas été conservées. Même l’ordre des tâches reportées pouvait être perdu.
« Jusqu’où sommes-nous allés hier ? »
« Le dossier a disparu. »
« Bon, retournons inspecter la porte. »
Laissez les Titans tranquilles : sauvez d’abord les archives.
Relancer le système ne garantit pas que les anciennes tâches seront terminées. On peut multiplier les départs sans jamais avancer sur le travail qui attend depuis le plus longtemps.
Rentrer sans encombre, ce n’est pas réussir la mission
Autre piège : le mot « succès ».
Pour un programme, il peut signifier qu’il s’est arrêté proprement, sans panne imprévue. Même une interruption volontaire faute de temps peut être enregistrée ainsi.
C’est peut-être exact techniquement. Mais pour le lecteur qui attend son article, cela ne répond à rien.
Le programme a démarré ? Oui. Les registres ont changé ? Oui. Il s’est arrêté proprement ? Oui.
Et le nouvel article, on peut le lire ? Pas encore.
Enregistrer, transmettre pour publication, afficher sur le site et vérifier le résultat sont quatre événements distincts. Une étiquette « succès » ne dit pas lequel a eu lieu.
Avant de recruter, finissons une expédition
On pourrait demander à une autre intelligence artificielle de jouer le commandant et d’enquêter sur chaque échec. Mais l’usine automatique finirait par ressembler à un bureau où le chef passe ses nuits à réécrire les rapports de mission.
Il faudrait plutôt terminer un article de bout en bout, conserver l’avancement en cas d’interruption et éviter qu’un seul texte défectueux bloque tous les autres. Les tâches administratives non essentielles peuvent attendre.
Le bon indicateur n’est pas le nombre de sorties, mais le nombre d’articles que les lecteurs peuvent réellement ouvrir.
À l’écran, « SUCCÈS » s’affiche encore.
Très bien. La prochaine fois, ramenez un article plutôt que le formulaire de départ.
Références (2)
[1] Site officiel de l’anime Attack on Titan, épisode 1.
[2] Explication japonaise de la réplique sur l’absence de résultat. Le cas d’automatisation provient de journaux d’exécution anonymisés.
