9 min de lecture - Revue d'architecture IA en 10 jours pour équipes legacy

La plupart des projets de « modernisation IA » n'échouent pas parce que le modèle est mauvais.

Ils échouent parce que le système qui entoure le modèle n'est pas défini : d'où viennent les données, quelles permissions s'appliquent, comment les réponses sont évaluées, ce qui se passe en cas d'erreur, et qui a le droit de le modifier.

C'est pourquoi une checklist de revue d'architecture est utile aux équipes qui gèrent un existant legacy. Il vous faut une revue courte et ciblée, qui transforme un « il faudrait ajouter de l'IA » en un plan exécutable, avec des périmètres, des risques et un backlog priorisé.

Ce que vous allez apprendre

• Ce que doit produire une revue d'architecture IA de 10 jours (des livrables, pas des opinions)
• Une checklist à dérouler sur les données, l'application, l'infrastructure, la sécurité et les opérations
• Les questions « incontournables » avant de déployer de l'IA dans une application legacy
• Un plan de rapport prêt à copier-coller, à partager avec la direction et les achats

L'essentiel

Une checklist de revue d'architecture IA sur 10 jours aide les équipes legacy à livrer plus vite et plus sûrement, en clarifiant les périmètres de données, le contrôle d'accès, l'évaluation et la responsabilité opérationnelle avant d'écrire la moindre ligne de code. Le résultat est un rapport concret : workflows cibles, registre des risques, options d'architecture recommandées et backlog priorisé. Cela évite la « prolifération de l'IA » et réduit les reprises lorsque la sécurité et les achats entrent en jeu.

Ce qu'est cette revue (et ce qu'elle n'est pas)

Ce n'est ni une réécriture qui s'étale sur des mois, ni un concours de sélection de fournisseur.

C'est une revue rapide destinée à répondre à ces questions :

• Que construit-on en premier ?
• Quel est le périmètre des données ?
• Comment mesure-t-on la qualité et les régressions ?
• Qui porte les opérations après le lancement ?
• Quels sont les principaux risques et leurs mesures d'atténuation ?

Si vous ne répondez pas à ces questions tôt, vous y répondrez plus tard, sous pression.

Le plan sur 10 jours (que faire chaque jour)

Le cadrage temporel est essentiel. Voici un calendrier pragmatique, adapté aussi bien aux grands comptes qu'aux PME avec un existant legacy.

Jours 1-2 : périmètre des workflows et « definition of done »

• Choisissez 1 à 2 workflows où l'IA changerait réellement les résultats (allègement du support, ingestion de documents, recherche interne).
• Rédigez des critères d'acceptation en langage clair : à quoi ressemble une « bonne réponse » et ce qui est inacceptable.
• Nommez les responsables : product owner, responsable technique et responsable opérationnel.

Jours 3-4 : périmètre des données et contrôle d'accès

• Recensez les sources (documentation, tickets, wikis, bases de données) et leur fréquence de mise à jour.
• Identifiez les catégories sensibles : données personnelles (PII), données clients, documents réglementés, secrets commerciaux.
• Définissez le modèle de permissions pour la récupération (rôles, équipes, cloisonnement client, zone géographique).
• Définissez ce qui est journalisé et pendant combien de temps cela est conservé.

Jours 5-6 : options d'architecture et plan d'évaluation

• Choisissez une approche candidate (RAG, fine-tuning, hybride) et documentez pourquoi.
• Définissez un dispositif d'évaluation : un jeu de référence (golden set) de questions/tâches réelles, une méthode de notation, et des seuils de mise en production/régression.
• Prévoyez les comportements de repli : citations, comportement de refus, intervention humaine (human-in-the-loop), circuits d'escalade.

Jours 7-8 : réalité opérationnelle (fiabilité et coûts)

• Définissez le monitoring : régressions de qualité, latence, coûts et volume d'incidents.
• Identifiez les modes de défaillance : réponses erronées, citations manquantes, fuites de permissions, indisponibilités d'outils.
• Construisez un modèle de coûts : ce qui pèse sur la dépense (taille du contexte, volume de requêtes, récupération, reranking).

Jours 9-10 : produire le rapport et le premier backlog de livraison

• Constituez un backlog sur 2 sprints (ce qu'il faut livrer, ce qu'il faut différer).
• Produisez un registre des risques avec mesures d'atténuation et responsables.
• Alignez les parties prenantes sur les critères de « go/no-go » pour la mise en production.

Le guide d'entretien avec les parties prenantes (questions à forte valeur)

Les équipes legacy ont généralement des contraintes cachées qui n'apparaissent qu'en entretien. Posez des questions qui font émerger la réalité opérationnelle :

• Produit/ops : « Qu'est-ce qui constitue un échec ? Qui s'énerve quand ça se passe mal ? »
• Sécurité/conformité : « Quelles données sont interdites ? Quelles preuves faut-il pour valider ce projet ? »
• Support/utilisateurs : « Que faites-vous aujourd'hui quand vous ne trouvez pas la réponse ? »
• Ingénierie : « Où journalise-t-on aujourd'hui ? Quel est le chemin de rollback quand une mise en production tourne mal ? »
• IT/plateforme : « Qu'est-ce qui est approuvé en matière d'accès, de SSO et de politique d'appareils ? Qu'est-ce que les achats vont bloquer ? »

L'objectif n'est pas de satisfaire chaque partie prenante en 10 jours, mais de capter les contraintes tôt, pour que votre architecture ne repose pas sur des suppositions.

Les pièges legacy qui reviennent à chaque fois

Les applications legacy échouent rarement à cause de la « logique IA ». Elles échouent à cause de la réalité de l'intégration :

• Pas de source de vérité propre : « La politique est dans un PDF, plus le wiki, plus le savoir tribal. » La récupération reflétera ce désordre, à moins de consolider ou de versionner les sources.
• Les permissions sont sociales : l'accès est accordé par messages Slack, pas par des rôles. Si vous ne pouvez pas faire respecter les permissions au moment de la récupération, ne déployez pas.
• Les logs ne sont pas sûrs par défaut : les systèmes legacy journalisent les payloads bruts. Si les prompts ou les réponses de l'IA contiennent du contenu sensible, il vous faut un plan de rédaction et de rétention.
• Pas de réflexe de rollback : les équipes savent déployer, mais pas revenir en arrière rapidement. Les évolutions liées à l'IA exigent une discipline de rollback, car les changements de comportement peuvent être subtils.

Signaler ces points dans le rapport n'a rien de pessimiste. C'est ce qui vous évite de cadrer une « simple fonctionnalité IA » qui se transforme en réécriture complète de la plateforme.

Checklist par couche (vue rapide)

Utilisez-la comme checklist de revue d'architecture pendant les entretiens et les revues de système.

• Produit et workflow
• Qui est l'utilisateur, et quelle décision le résultat vient-il éclairer ?
• Quel est l'impact d'un échec (gênant, coûteux ou dangereux) ?
• Données
• Où réside la vérité ? À quelle fréquence change-t-elle ?
• Pouvez-vous faire respecter les permissions au moment de la récupération ?
• Modèle et prompts
• Disposez-vous d'un golden set et de seuils ?
• Avez-vous un plan de rollback pour les changements de prompt ou de modèle ?
• Application
• Par où le résultat de l'IA entre-t-il dans le système (interface, API, automatisation) ?
• Comment gérez-vous les échecs partiels et les relances ?
• Ops et gouvernance
• Qui est d'astreinte en cas d'incident ?
• Qu'est-ce qui est journalisé, expurgé et conservé ?
• Comment détectez-vous les régressions avant vos utilisateurs ?

À copier-coller : le plan de rapport attendu par la direction

Que vous livriez ce travail en tant que consultant ou en tant qu'équipe plateforme interne, produisez un rapport qui se lit comme un manuel d'exploitation, pas comme un jeu de slides.

Le registre des risques (court, mais réel)

Une bonne revue d'architecture ne se contente pas de lister des options. Elle liste des risques, avec leurs responsables.

Exemples de risques à consigner :

• fuite de permissions (responsable : sécurité + plateforme)
• régressions de qualité après un changement de prompt ou de modèle (responsable : lead engineering)
• pics de coûts liés à un contexte long ou au reranking (responsable : plateforme)
• échec d'adoption (responsable : produit/ops)

Pour chaque risque, indiquez une mesure d'atténuation et une méthode de détection (« comment allons-nous le repérer tôt ? »). Cette seule ligne fait souvent la différence entre « nous avons anticipé » et « nous avons espéré ».

Executive summary (1 page)
- Target workflow(s)
- Recommended architecture option(s)
- Key risks and mitigations

Current-state snapshot
- Systems and data sources
- Access control model
- Operational ownership

Proposed architecture
- Data boundary and permissions
- Evaluation harness and thresholds
- Observability and incident response

Delivery plan
- Sprint 1 backlog
- Sprint 2 backlog
- Dependencies and decisions needed

Constats fréquents chez les équipes legacy

Les équipes legacy découvrent généralement l'un de ces schémas :

• Une « base de connaissances » qui n'est en réalité que cinq wikis et un drive partagé sans responsable.
• Des permissions qui existent socialement (« demandez à Bob ») mais pas techniquement.
• Aucune référence d'évaluation, si bien que chaque débat entre parties prenantes devient subjectif.
• Un trou dans les opérations : personne ne sait qui gère les incidents une fois l'IA en production.

Corriger ces points n'a rien de gratifiant, mais c'est ce qui rend la livraison possible.

Si cette revue est bien menée, la planification des sprints devient plus simple : moins d'inconnues, moins de retards du type « on a découvert le problème de sécurité trop tard », et moins de réécritures, car l'équipe s'est enfin mise d'accord sur ce que signifie « bien ».

Évitez le gaspillage le plus coûteux : construire deux fois la même chose

Le travail de revue d'architecture est rentable, car il évite un gaspillage bien précis : construire la même chose deux fois. En clarifiant les périmètres de données, l'évaluation et les responsabilités avant l'implémentation, vous livrez plus vite et vous arrêtez de débattre de la « qualité de l'IA » sur la base de ressentis plutôt que de seuils mesurables. Besoin d'aide pour mener une revue d'architecture sur votre stack legacy ? Parlons-en.