Ton prototype IA fonctionne. Maintenant, qui répond quand il tombe en panne ? | IA BLOG

Le premier jour, tout le monde trouve ça formidable.

Une petite application fabriquée avec de l'IA, un formulaire qui remplit un tableau, quelques automatisations et un résultat disponible en quelques minutes. Le prototype tourne. Le client sourit. On commence déjà à imaginer la version suivante.

Puis quelqu'un pose une question beaucoup moins amusante : « Et si ça ne marche plus dans six mois, on appelle qui ? »

Silence.

C'est souvent là que commence le vrai travail d'éditeur de logiciel. Pas au premier écran. Au moment où l'on accepte que d'autres personnes vont dépendre de ce que l'on vient de créer.

Une date qui mérite l'attention des éditeurs

Le 11 septembre 2026, une partie des obligations du règlement européen sur la cyberrésilience, ou Cyber Resilience Act (CRA), est devenue applicable. La Commission européenne rappelle que les fabricants de produits comportant des éléments numériques doivent notifier certaines vulnérabilités activement exploitées et certains incidents graves touchant la sécurité de leurs produits.

Les délais prévus comprennent une alerte initiale sous 24 heures et une notification plus complète sous 72 heures. D'autres rapports suivent selon la nature de l'événement. Les obligations principales de conformité du règlement, quant à elles, doivent s'appliquer à partir du 11 décembre 2027.

Ce calendrier ne signifie pas que chaque script interne créé avec de l'IA est automatiquement soumis aux mêmes obligations. Le champ du règlement dépend notamment de la nature du produit, de sa mise à disposition sur le marché de l'Union européenne et du rôle de l'acteur concerné. Un outil utilisé seulement en interne, un développement réalisé pour un client et un logiciel distribué à plusieurs entreprises ne se qualifient pas nécessairement de la même manière.

La distinction demande une analyse réelle, pas une conclusion faite à partir du mot « IA ».

Source : Commission européenne, Safer and more secure digital products, 11 septembre 2026.

Le problème existait avant le règlement

Prends un assistant qui aide à trier des commandes. Au départ, il récupère un fichier, rapproche quelques références et propose une liste d'anomalies. L'équipe contrôle, corrige et gagne du temps.

Quelques semaines plus tard, on lui ajoute une connexion au logiciel commercial. Puis une autre. Il commence à écrire dans les dossiers, à déclencher des traitements et à envoyer des notifications.

À chaque ajout, l'outil devient plus utile. Mais il devient aussi plus difficile à comprendre de l'extérieur.

Qui connaît les droits qu'il possède ? Où se trouve sa version précédente ? Est-ce que quelqu'un peut désactiver une fonction sans supprimer les données ? Qui constate qu'une mise à jour a changé son comportement ?

Ce n'est pas parce qu'une IA a aidé à écrire le code que ces questions ont disparu. Au contraire, lorsqu'on produit vite, on peut accumuler très vite les décisions que personne n'a eu le temps de documenter.

Et une application qui rend service crée une dépendance, même si elle a commencé comme un bricolage sympathique.

Vendre un résultat, c'est aussi vendre la suite

Une démonstration répond à une question : « Est-ce faisable ? »

Un logiciel utilisé au quotidien doit répondre à d'autres questions. Que se passe-t-il si un service extérieur change son API ? Comment corrige-t-on une erreur sans perdre le travail déjà réalisé ? Si le client part, peut-il récupérer ses données dans un format utilisable ? Et qui décide qu'une version est suffisamment testée pour être déployée ?

Ce sont les coulisses du produit. On ne les voit pas dans une maquette. Elles coûtent pourtant du temps, des compétences et parfois de l'argent.

Pour un petit éditeur, tout prévoir dès le premier jour serait absurde. Une application interne de dix lignes n'appelle pas la même organisation qu'un produit vendu à plusieurs clients. Mais il faut savoir à quel moment l'outil change de catégorie.

Ce moment arrive souvent lorsqu'il franchit l'une de ces frontières : une autre équipe l'utilise, il manipule des données importantes, il obtient le droit de modifier des systèmes, ou quelqu'un d'extérieur s'appuie sur lui pour travailler.

Là, un petit dossier de maintenance devient raisonnable : version exacte, dépendances, accès autorisés, sauvegarde, procédure d'arrêt, méthode de mise à jour et personne à contacter.

Cela ressemble moins à une invention spectaculaire qu'à un carnet d'entretien. Et c'est précisément son intérêt.

Le bon réflexe avant une mise sur le marché

Si tu développes ou distribues une application, commence par distinguer ce qui relève de ton rôle contractuel, de tes engagements de service et, le cas échéant, des obligations réglementaires applicables au produit.

Le CRA mérite alors un examen spécifique. Le RGPD peut s'ajouter si des données personnelles sont traitées. L'AI Act peut soulever d'autres questions selon l'usage du système. Ces textes n'ont ni le même objet ni forcément le même périmètre. Les mélanger en une seule liste de cases cochées ne suffit pas à être conforme.

Tu n'as pas besoin de transformer chaque prototype en usine documentaire. Tu as besoin de savoir quand tu passes de « je peux le faire » à « je peux le maintenir et en répondre ».

Ce que je retiens

Il y a une joie très réelle à construire un outil en une après-midi. Je ne vais pas faire semblant du contraire.

Mais une fois l'application confiée à d'autres, la prouesse initiale devient secondaire. Ce qui compte, c'est qu'elle continue à fonctionner, qu'on puisse la corriger et que personne ne découvre ses limites au pire moment.

Avant de demander à ton IA de créer la prochaine fonction, pose cette question : si cette application disparaît demain, sais-tu exactement comment reprendre la main ?

Une réponse claire vaut bien quelques fonctionnalités de moins.