Le contremaître de l'IA : le rôle du COO

Lorsque nous concevons un système où plusieurs rôles travaillent en parallèle, le premier problème que nous rencontrons n'est pas technique. C'est une question discrète mais incontournable : qui approuve quoi, et dans quel ordre ?

Dans notre conception initiale, nous avions centralisé l'approbation en un seul point d'entrée. Les propositions et l'avancement de chaque rôle y étaient rassemblés et vérifiés au même endroit. Ce système était simple à comprendre, et il avait l'avantage de centraliser aussi les enregistrements.

Mais en le faisant fonctionner réellement, un autre problème est apparu. Plus les dossiers s'accumulaient, plus les demandes d'approbation s'empilaient à ce point unique. Pendant cette attente, le travail des autres rôles concernés s'arrêtait aussi. Les dossiers urgents et les dossiers non urgents se retrouvaient dans la même file, et l'ordre des priorités finissait par se décider au coup par coup. Personne ne faisait rien de mal, et pourtant l'ensemble avançait de plus en plus lentement. Ce n'est pas un incident visible, mais un blocage qui s'accumule peu à peu. Dans cette série, nous appelons cet état l'« effondrement silencieux ».

Isoler un rôle de contremaître

Pour ne pas laisser cet état s'installer, nous avons créé le COO (ici : le rôle qui pilote le fonctionnement quotidien de l'organisation). Si l'on prend l'image d'un chantier, ce n'est ni la personne qui dessine les plans, ni celle qui donne la décision finale, mais le contremaître qui décide dans quel ordre les tâches du jour doivent avancer.

Le travail du COO se divise globalement en deux volets. Le premier est la priorisation transversale (décider dans quel ordre traiter les dossiers venant des différents rôles). Le second est le suivi de l'avancement (vérifier que les choses avancent réellement dans l'ordre décidé, et repérer les points de blocage en cours de route).

Le COO ne prend pas lui-même les décisions importantes. Ces décisions passent par le mécanisme de consultation que nous avons vu dans les parties précédentes. Ce dont le COO s'occupe, c'est de la régulation du trafic en amont : quel dossier envoyer d'abord à la consultation, et quel dossier peut se contenter d'une simple vérification. C'est ce tri qui constitue son rôle.

Ne pas recréer une centralisation de l'approbation

Voici un point auquel nous devons faire attention. Si la centralisation de l'approbation en un seul point était la cause de l'« effondrement silencieux », remplacer ce point unique par le COO ne fait que reproduire le même problème ailleurs. Le COO lui-même risquerait alors de devenir le nouveau goulot d'étranglement (ici : un point où tout le flux se concentre et finit par se bloquer), en s'interposant sur chaque dossier.

Pour éviter cela, nous avons posé deux limites au rôle du COO. La première : le COO ne détient pas la décision finale. Il assure le tri et le suivi, mais laisse le contenu — approuver ou non — à la consultation de chaque rôle. La seconde : les critères de tri sont fixés à l'avance sous forme de règles. Plutôt que de laisser le COO juger au cas par cas à chaque dossier, nous décidons à l'avance quelle voie suivre selon le poids et l'ampleur de l'impact du dossier. Une fois ces critères fixés, le système se bloque moins facilement, même en l'absence du COO.

Un rôle discret, mais dont on remarque l'absence

Le rôle du contremaître est d'autant moins visible que tout fonctionne bien. Mais en faisant tourner le système, nous avons compris ceci : sans cette régulation discrète, même si les autres rôles prennent d'excellentes décisions, le temps qu'il leur faut pour atteindre le terrain s'allonge peu à peu.

Le rôle du COO n'est pas de rendre les décisions meilleures. Il sert à garder aussi court que possible le trajet entre le moment où une décision naît et le moment où elle se met réellement en mouvement. Ne pas centraliser l'approbation en un seul point, mais sans quelqu'un pour piloter, rien n'avance non plus. C'est pour tenir cet équilibre que nous avons isolé ce rôle.