Construire en dernier : une règle d'approvisionnement pour les outils de gouvernance de l'IA

La pertinence de la mission et l'effort déjà investi ne justifient rien. La seule chose qui justifie de construire est une recherche infructueuse qui a été documentée.

Le réflexe

La séquence est assez familière pour être récitée. Une lacune en matière de gouvernance apparaît lors d'un audit. Rien sur le marché ne correspond exactement. Quelqu'un a déjà construit quelque chose de connexe. Apparaît un tableur, puis un script, puis une application interne avec deux mainteneurs et pas de feuille de route. Dix-huit mois plus tard, elle est essentielle pour une obligation de conformité et un mainteneur est parti.

Personne n'a fait de mauvais choix. Chaque étape était localement raisonnable, et l'agrégat est une dépendance non financée dans un chemin de contrôle réglementé. La règle que je m'impose : adopter en premier, soutenir ce qui peut être légitimement trouvé à l'extérieur, construire en dernier recours. Forte de conviction, car le réflexe qu'elle oppose est fort et l'échec qu'elle prévient apparaît des années après la décision qui en est la cause.

Les trois portes

Cette règle n'est utile que comme questions auxquelles on répond avant le premier engagement.

Existe-t-ce ? Pas « est-ce qu'un produit résout cela exactement », ce qui est presque toujours non et est la mauvaise question. Est-ce que quelque chose résout 70 %, le reste étant un processus plutôt qu'un logiciel ? La plupart des lacunes en matière de gouvernance sont comblées par un outil existant plus une décision que personne ne veut prendre, et construire nous permet d'éviter cette décision. Recherchez les produits commerciaux, les projets open-source, les organismes de normalisation avec des implémentations de référence, et ce qui a été construit pour un problème voisin. Ce dernier élément contient la plupart des réponses manquées.

Pouvons-nous le soutenir ? Un outil que nous ne pouvons pas exploiter n'est pas une réponse. Cette porte concerne la licence qui survit à notre cas d'utilisation, la maintenance qui ne repose pas sur un seul bénévole en amont, la gestion des données qui répond à nos obligations, et une issue. Une dépendance que nous ne pouvons pas quitter est une dépendance que nous avons mal évaluée. Soutenir signifie aussi contribuer : financer ou corriger les derniers 30 % bat généralement la construction de 100 %, et laisse la capacité là où quelqu'un d'autre la maintient.

La lacune survit-elle au contact ? Après les deux premières portes, reformulez-la en une phrase. Souvent, elle s'est réduite à quelque chose qui n'est pas un problème logiciel : une politique jamais écrite, un seuil que personne ne fixerait, un rôle manquant dans l'organigramme. Ces éléments ne se ferment pas par la construction. Construire dessus produit un outil qui encode la décision non prise et rend plus difficile le retour sur cette décision.

La pertinence de la mission ne justifie rien

Deux arguments arrivent ici, et les deux doivent être clairement refusés.

Le premier est la pertinence de la mission. « Ceci est au cœur de ce que nous faisons, nous devons donc en être les propriétaires. » Être propriétaire et construire sont deux décisions différentes, et la seconde ne découle pas de la première. Une entreprise dont la mission est le jugement juridique ne rédige donc pas son propre système de gestion documentaire. La compétence essentielle plaide pour le contrôle de l'interface et des données, pas pour l'authentification de l'implémentation.

Le second est l'effort déjà investi. « Nous avons déjà consacré quatre mois à cela. » Quatre mois nous renseignent sur le passé et rien sur les quatre mois suivants. C'est ce qu'on croit, et c'est pourquoi cela nécessite une règle plutôt qu'un jugement au moment présent.

Les deux sont du genre de raisonnable qui survit à une réunion, c'est pourquoi les portes sont répondues par écrit au préalable.

Documenter la recherche

Les portes ont peu de valeur prises isolément. Ce qui rend la règle puissante, c'est l'artefact : un enregistrement de ce qui a été recherché, de ce qui a été trouvé, et de pourquoi cela ne convenait pas. Six mois plus tard, quelqu'un rencontre la même lacune sous un autre angle, et sans le document, il refait la même recherche maladroitement et construit un deuxième outil.

Un enregistrement utilisable comporte quatre parties et tient sur une page :

1. La lacune, en une phrase, telle qu'elle était avant la recherche.
2. Ce qui a été évalué, y compris les outils connexes considérés et mis de côté.
3. Pourquoi chacun a échoué à une porte, en nommant laquelle.
4. La date, car cela expire.

Ce dernier point est plus important qu'il n'y paraît : une décision de construire justifiée par une recherche datant de deux ans n'est justifiée par rien.

Nous appliquons cela à nous-mêmes

Je préfère énoncer la version inconfortable plutôt que la flatteuse. Chaque composant de notre portefeuille existe parce qu'une capacité manquait dans le travail réel et que la recherche n'a pas été concluante. C'est exactement l'affirmation que fait trop facilement un fondateur, donc la règle s'applique le plus fortement à nous. Le test de l'adoption en premier ne devient pas plus facile parce que nous avons déjà écrit l'outil. Là où une norme ou un projet externe peut couvrir une partie de ce que nous avons construit, le bon réflexe est de l'adopter et de retirer le nôtre. Certaines de ces décisions sont encore ouvertes.

Quand la construction est justifiée

La règle n'est pas « ne jamais construire ». Construire est le dernier recours et doit être entrepris délibérément, lorsque la recherche a échoué sur le document, que la lacune a survécu à la troisième porte, et que la construction a un propriétaire, un budget et un état final. Ce qu'elle empêche, c'est l'autre chemin, celui où nous arrivons à une dépendance interne personnalisée sans jamais avoir décidé de le faire.

La prochaine fois qu'une lacune en matière de gouvernance apparaît, le premier artefact ne doit pas être un prototype. Il doit être la page indiquant ce qui existe déjà.

---

Prêt à savoir quelles lacunes en matière de capacité sont réelles avant de construire pour elles ? Découvrez PAICE pour les organisations ou faites une évaluation individuelle pour le constater par vous-même.

---

Lectures recommandées

• Gouvernance IA Collaboration - Là où la politique se termine et l'outillage commence
• Construire votre boîte à outils IA Collaboration - Assembler à partir de ce qui existe
• Évaluation du business case pour l'IA Collaboration - Ce dont l'approvisionnement a besoin
• Le guide du dirigeant pour la préparation à l'IA Collaboration - Ce qui vaut la peine d'être possédé