L’ingénierie logicielle de l’IA au-delà de la démonstration

Contrat système

Spécifier le comportement là où les exigences classiques s’arrêtent

Un logiciel classique peut souvent être testé contre une sortie exacte. Un composant d’IA peut donner plusieurs réponses acceptables, tandis qu’une réponse plausible peut rester matériellement fausse. La spécification doit donc contenir des exemples, des grilles et des tolérances liées à la décision de l’utilisateur. Précisez ce qui doit être présent, ce qui ne doit jamais apparaître, quand les sources sont obligatoires et quand le système doit déclarer qu’il ne peut pas continuer. Une variation de style n’est pas un échec de fait, d’autorisation ou d’action.

Le contrat se place à la frontière du système. Une classification correcte n’est pas un succès si l’application l’attache au mauvais dossier ou si la personne concernée ne peut pas la contester. Incluez qualité des données, interface, contrôle humain et solution de repli. Le cadre de gestion des risques IA du NIST organise le travail autour de la gouvernance, de la cartographie, de la mesure et de la gestion. Il rappelle que la précision technique n’est qu’une propriété d’un déploiement digne de confiance.

• Définir objectif, contexte, utilisateurs et usages interdits.
• Classer les échecs par conséquence et pas seulement par fréquence.
• Préciser preuve, incertitude et escalade.
• Tester le parcours complet de l’utilisateur et des systèmes aval.
• Rendre les critères observables avant l’implémentation.

Architecture

Entourer la capacité probabiliste d’un plan de contrôle déterministe

Le modèle n’est pas la source de vérité pour l’identité, les droits, l’état du processus ou l’approbation. Le code authentifie l’utilisateur, filtre les données avant recherche et valide chaque résultat structuré contre des types et invariants métier. Un appel d’outil reste une proposition jusqu’à l’autorisation côté serveur de l’acteur, de la ressource et des paramètres. Une opération conséquente exige idempotence, confirmation et résultat durable du système cible. Le récit du modèle ne prouve jamais l’exécution.

La reproductibilité exige plus qu’un commit Git. Conservez ensemble version de l’application, identifiant du modèle, réglage du fournisseur, prompt, index de recherche, instantané de données ou pipeline de variables, politique et schéma des outils. Établissez un inventaire adapté des composants et fournisseurs. Le Secure Software Development Framework du NIST intègre la sécurité au cycle de développement. Les dépendances IA ajoutent des artefacts et des canaux de changement, sans remplacer environnements protégés, revue des changements et correction des vulnérabilités.

Livraison

Faire de la preuve d’évaluation un artefact de livraison

Les tests unitaires restent indispensables aux analyseurs, autorisations, transformations et intégrations, mais ils ne définissent pas l’enveloppe comportementale d’un système dépendant d’un modèle. Maintenez des jeux pour trafic ordinaire, entrées difficiles, preuves absentes, bords de distribution, plusieurs langues et attaques. Notez séparément soutien factuel, complétude, sûreté de l’action, validité du format, calibration et résultat utilisateur. Une moyenne pondérée ne doit jamais compenser un échec critique de sécurité.

Reliez chaque version candidate à son rapport d’évaluation, ses limites, son approbation et son plan de déploiement. Comparez-la à la production actuelle plutôt qu’à une impression. L’évaluation fantôme convient aux chemins en lecture; un petit canari sert lorsque l’interaction réelle est nécessaire. Définissez des arrêts automatiques pour les signaux graves et un responsable humain pour les preuves ambiguës. Prompts, politiques de recherche et configuration du modèle suivent le même chemin contrôlé que le code, car ils modifient le comportement visible.

• Conserver un jeu de réserve protégé pour une comparaison honnête.
• Rapporter les résultats par risque, famille de cas et langue.
• Appliquer une tolérance nulle aux échecs critiques définis.
• Relier chaque changement à sa preuve et son approbation.
• Déployer avec exposition bornée et retour arrière vérifié.

Exploitation

Apprendre de la production sans abandonner le contrôle

La surveillance commence par le résultat utilisateur. Vérifiez si la tâche est terminée, si une personne a corrigé ou annulé le résultat, si les pièces étaient valides et si une action externe a été confirmée. Ajoutez signaux du modèle et de l’infrastructure: consommation, qualité de recherche, latence, erreur d’outil et refus. Segmentez par version et famille de cas pour qu’une moyenne stable ne cache pas une régression concentrée. Ne capturez que le contenu nécessaire au diagnostic déclaré, avec accès et conservation adaptés.

Lors d’un incident, contenez d’abord l’exposition: désactivez un outil, dirigez vers le contrôle manuel, revenez au modèle précédent ou arrêtez la fonction. Préservez versions et événements, puis reproduisez avec un cas minimisé. Situez le défaut dans les données, le prompt, le modèle, la recherche, la politique, l’intégration, l’interface ou l’exploitation. Corriger la mauvaise couche crée un pansement fragile. Ajoutez un cas de régression approuvé, consignez la décision et vérifiez le rétablissement.

• Surveiller les résultats terminés, pas seulement les réponses du modèle.
• Segmenter les tendances pour rendre visible un dommage localisé.
• Minimiser la télémétrie sensible et limiter sa conservation.
• Contenir un incident actif avant de le diagnostiquer.
• Transformer les échecs confirmés en preuves de régression durables.