Ce qui se joue avant le choix du modèle

Le choix du modèle occupe l'essentiel des discussions de démarrage et il sera repris deux à trois fois dans l'année. Les trois décisions qui le précèdent, elles, suivront le système toute sa vie.

Ce déséquilibre a une explication simple : le modèle est la partie visible, celle qui a un nom, un prix affiché et des classements publics. Elle se discute facilement.

Le cadrage, l'état du corpus et le mode d'intégration n'ont ni nom ni classement. Ils se discutent mal et ils décident du résultat.

Sur les systèmes que j'ai repris, aucun n'échouait à cause du modèle. Tous échouaient sur l'un des trois autres.

Un cadrage utile produit une liste de ce qui est écarté, pas seulement de ce qui est retenu. C'est la partie qui rapporte le plus et qui ne laisse aucun livrable visible.

Sur cinq cas d'usage présentés, deux au plus méritent d'être poursuivis. Les trois autres échouent pour des raisons identifiables dès le départ : corpus indisponible, absence de propriétaire, résultat invérifiable.

Écarter ces trois-là évite trois projets qui auraient consommé leur budget avant de s'arrêter. Le raisonnement complet figure dans combien de cas d'usage faut-il abandonner.

La forme compte : un cas écarté doit être remplacé par une condition explicite de réouverture, sinon l'exercice est vécu comme un refus.

Brancher le système sur les applications existantes prend plus de temps que tout le reste, et la moitié d'entre elles n'expose aucune interface programmable. C'est le poste le plus sous-estimé au cadrage.

Le travail administratif d'une organisation se déroule dans des progiciels installés il y a dix ou quinze ans, dont l'éditeur facture cher toute évolution.

Trois ponts existent : l'export de fichiers, la lecture en base, et le pilotage de l'écran. Ils n'ont ni le même coût ni la même fragilité, et le plus visible est presque toujours le pire. Le choix se fait sur trois critères, détaillés dans brancher un modèle sur un progiciel sans API.

Cette question doit être instruite au cadrage, parce qu'elle peut à elle seule disqualifier un cas d'usage par ailleurs excellent.

Une couche d'abstraction, un jeu de tests, et un palier par défaut. Le reste se règle en deux heures à chaque revue. C'est tout ce que la question du modèle mérite au démarrage.

La couche d'abstraction isole l'appel et rend le changement trivial. Elle coûte une demi-journée et évite une réécriture au douzième mois, comme développé dans la couche qui rend le modèle remplaçable.

Le jeu de tests donne le critère de décision. Sans lui, chaque comparaison redevient une discussion d'opinion.

Le palier par défaut se choisit intermédiaire, puis se révise à la baisse là où les tests le permettent. Partir du palier supérieur par précaution coûte cher sans améliorer les tâches qui composent l'essentiel du volume.

Le jeu de tests devrait être le premier livrable, avant la première réponse correcte du système. C'est contre-intuitif et c'est ce qui distingue les projets qui avancent.

Construit avant, il définit ce que « bon » veut dire, et il oblige à répondre à la question du succès pendant que la réponse est encore négociable.

Construit après, il entérine ce que le système fait déjà et perd toute valeur d'arbitrage : on ne s'en sert plus pour décider, seulement pour constater.

Sa constitution prend une journée, et il se rembourse à chaque changement de modèle, soit deux à trois fois par an, indéfiniment. La méthode figure dans construire un jeu de tests en une journée.

Une objection revient à ce stade : comment définir le succès avant d'avoir vu ce que le système sait faire. Elle est légitime et elle se retourne. C'est précisément parce qu'on ne l'a pas vu qu'on peut encore définir le succès sur le besoin plutôt que sur la performance constatée. Trente cas réels, avec la réponse attendue par une personne du métier, se constituent sans qu'aucun système n'existe.