Êtes-vous prêt pour un build IA de 8 semaines ? Une liste de préparation

Évaluez-vous honnêtement sur les cinq domaines ci-dessous. Un « non » n'est pas une disqualification — c'est une chose à corriger avant que l'horloge démarre. L'intérêt de la liste est de faire remonter les lacunes maintenant, quand elles sont peu coûteuses à combler, plutôt qu'en semaine trois d'un build, quand elles coûtent cher.

Fort sur les cinq : vous êtes prêt à construire. Faible sur un : corrigez-le d'abord. Faible sur deux ou plus : commencez par un Diagnostic, qui existe précisément pour résoudre ces inconnues.

1) Préparation des données — des données représentatives existent-elles, sont-elles accessibles et assez bonnes pour bâtir des evals ? 2) Alignement des parties prenantes — y a-t-il un décideur unique qui possède le résultat, pas un comité ? 3) Critères de succès — pouvez-vous dire ce que « fonctionne » signifie en termes mesurables ? 4) Accès à l'infrastructure — une équipe peut-elle provisionner dans votre environnement sans une chaîne d'approbation de plusieurs mois ? 5) Engagement commercial — le budget et le calendrier de huit semaines sont-ils réellement engagés ?

Ces domaines correspondent directement aux quatre principes : données et critères de succès alimentent les evals ; l'accès à l'infrastructure permet l'infrastructure possédée ; l'engagement rend l'horloge fixe réelle.

Si vous êtes fort sur les cinq, un Build peut démarrer en confiance et le prix fixe est peu risqué. Si les données ou les critères de succès sont faibles, c'est exactement ce qu'un Diagnostic produit — il cartographie le goulot et écrit la spécification d'evals, transformant un « pas encore » en « prêt ».

Si la lacune est l'alignement ou l'engagement, corrigez cela avant de dépenser le moindre euro en ingénierie. Aucune méthodologie ne survit à un build que l'organisation n'a pas réellement engagé.

Un score fort signifie que votre prochaine étape est un Diagnostic pour verrouiller le périmètre et chiffrer le Build — court, car vous êtes déjà prêt. Un score mitigé signifie que le Diagnostic fait double emploi : il comble les lacunes de préparation et produit le plan de build.

Dans tous les cas, la liste a fait son travail si elle a déplacé un problème de la semaine trois d'un build à la semaine qui le précède.

La liste se lit comme cinq scores indépendants, mais en pratique ils interagissent, et c'est dans ces interactions que se joue le vrai jugement. La force d'un domaine peut compenser la faiblesse d'un autre — ou la révéler. Un décideur engagé au calendrier dégagé peut remettre vite des données en désordre en état, donc un « non » sur les données accompagné d'un « oui » solide sur l'alignement des parties prenantes est une position récupérable. L'inverse ne l'est pas : des données impeccables derrière un comité sans propriétaire restent en général inutilisées, car personne n'a le pouvoir de décider ce que signifie « assez bon ».

Les deux domaines qui ne peuvent pas être compensés sont l'alignement des parties prenantes et l'engagement. Ils sont en amont de tout le reste — ce sont eux qui financent le travail qui comble les autres lacunes. Les données, les critères de succès et l'accès à l'infrastructure sont tous des choses qu'un Diagnostic peut résoudre, car ce sont des problèmes d'ingénierie et d'information. L'alignement et l'engagement sont organisationnels, et aucune dose de méthode ne s'y substitue. Si vous pesez un score mitigé, pondérez fortement ces deux-là et traitez les trois techniques comme comblables.

Il existe aussi un couplage caché entre les données et les critères de succès : on ne peut souvent pas écrire une définition mesurable de « fonctionne » avant d'avoir regardé des données représentatives, et on ne peut pas juger si ses données sont assez bonnes avant de savoir ce qu'on cherche à mesurer. C'est l'œuf et la poule, et c'est exactement pourquoi le Diagnostic traite les deux dans les mêmes deux semaines plutôt que séquentiellement — la spécification d'evals et l'évaluation des données s'écrivent ensemble parce que chacune dépend de l'autre.

La règle — fort sur cinq, on construit ; faible sur deux ou plus, on diagnostique d'abord — tient dans le cas ordinaire, mais quelques situations la cassent, et il vaut la peine de les nommer franchement. La première est le faux « oui » sur les données. Beaucoup d'opérateurs se notent forts parce que les données existent quelque part, pour découvrir en semaine deux qu'elles ne sont pas étiquetées, incohérentes entre systèmes, ou bloquées derrière un export que le juridique met six semaines à approuver. Exister n'est pas la même chose qu'accessible-et-représentatif ; si vous ne pouvez pas mettre un échantillon devant un ingénieur cette semaine, notez-le honnêtement « pas encore ».

La deuxième est le faux « oui » sur les critères de succès. Une cible comme « réduire le temps de traitement » semble mesurable mais n'est pas un eval — c'est un résultat sans définition par entrée de ce qu'est une bonne réponse. Le vrai test est plus étroit : pour une seule entrée représentative, pouvez-vous dire ce que le système devrait produire et comment vous jugeriez s'il l'a fait ? Si vous ne le pouvez pas, vous avez un objectif métier, pas un critère de succès, et la lacune est plus grande que ne le suggère le score.

Le troisième cas limite est l'inverse : un cinq sur cinq parfait sur un problème trop petit pour nécessiter le moindre Build de huit semaines. La préparation mesure si vous pouvez construire, pas si vous devriez. Une entreprise pleinement prête avec un problème d'une semaine est mieux servie par un travail étroitement cadré que par le paiement d'une horloge dont elle n'a pas besoin — et un Diagnostic honnête le dira plutôt que de pousser le Build.

Le premier mauvais usage est de noter avec optimisme pour justifier une décision déjà prise. La liste ne fonctionne comme diagnostic que si vous la laissez renvoyer une réponse inconfortable ; notée pour confirmer un build auquel vous vous êtes déjà engagé en interne, elle devient du théâtre. La discipline est de traiter chaque « oui » comme une affirmation qu'il vous faudrait défendre par des preuves en semaine un — si vous peiniez à produire ces preuves, c'est un « non ».

Le deuxième est de traiter les cinq domaines comme une porte à franchir une fois plutôt qu'un état à maintenir. La préparation peut se dégrader : le propriétaire responsable est réaffecté, le budget est réalloué en milieu de trimestre, la source de données que vous aviez évaluée est migrée. Un score pris trois mois avant le démarrage d'un build peut être périmé au moment où l'horloge démarre. Refaites-le près de la date de démarrage réelle, car le coût d'une condition préalable qui a discrètement expiré est le même qu'elle n'ait jamais été là ou qu'elle ait simplement disparu.

Le troisième mauvais usage est d'utiliser la liste pour noter un prestataire plutôt que vous-même. Elle est conçue pour évaluer votre côté de la mission — les conditions préalables que vous contrôlez. La méthode du prestataire, sa discipline d'evals et sa posture sur l'infrastructure sont une question distincte. Un score de préparation fort et un prestataire faible produisent quand même un mauvais build ; la liste retire la moitié du risque qui vous appartient, pas celle qui appartient à qui vous embauchez.

La liste n'est pas un substitut au Diagnostic — c'est l'entrée qui détermine ce que le Diagnostic vous coûte en temps et en attention. Un cinq sur cinq net ne signifie pas que vous sautez le cadrage ; il signifie que le Diagnostic de deux semaines passe son temps à confirmer et verrouiller plutôt qu'à découvrir, et que le devis de Build qui en résulte arrive plus vite et avec une fourchette plus serrée. Un score mitigé signifie que les mêmes deux semaines font double emploi, comblant les conditions préalables ouvertes et produisant le plan de build en une seule passe, ce qui est précisément ce que le Diagnostic est cadré pour absorber.

Ce qui change entre les deux cas, c'est où va l'effort du Diagnostic, pas le fait que vous en ayez besoin. Avec des données et des critères solides, le Diagnostic se concentre sur l'architecture et les seuils d'evals ; avec des faibles, il passe ses premiers jours sur l'accès aux données et à transformer un objectif métier en une définition scorable du « terminé ». Dans les deux cas, le livrable est le même — un goulot cartographié, une spécification d'evals et un périmètre de Build à prix fixe — mais le score de préparation vous dit à l'avance quelles conversations seront difficiles.

C'est aussi pourquoi plus de 60 % des Diagnostics débouchent sur un Build : au moment où le Diagnostic se termine, les lacunes de préparation qui auraient autrement émergé en cours de build ont déjà été résolues ou nommées. La limite honnête de la liste est qu'elle ne peut pas faire cette résolution elle-même — elle peut seulement vous dire si le Diagnostic sera une courte confirmation ou un travail de fond plus long. Les deux sont des points de départ légitimes ; le seul mauvais geste est de démarrer l'horloge du Build avec les lacunes encore ouvertes.