Audit technique d’un prototype IA : les 12 points qui comptent

Un audit technique de prototype IA répond à une question simple : l’application peut-elle accueillir de vrais utilisateurs, encaisser des paiements ou traiter des données sans faire courir un risque que personne n’a évalué ?

Regarder si le code est « propre » ne suffit pas. Il faut suivre les parcours réels, examiner les accès, provoquer des erreurs, vérifier les données et comprendre comment l’application est mise en ligne.

Les douze points que je regarde en priorité ne donnent pas une note abstraite au projet. Ils permettent de décider quoi garder, corriger, reprendre ou refaire.

1. Les parcours qui portent le produit

Je commence par ce que l’utilisateur vient réellement faire : créer un compte, déposer une demande, inviter un collègue, payer, consulter un dossier ou exporter un résultat.

L’objectif est d’identifier les parcours qui doivent tenir sans surveillance. Une page secondaire imparfaite n’a pas le même poids qu’un paiement qui peut être enregistré deux fois ou qu’un dossier qui disparaît après validation.

L’audit doit donc relier chaque constat technique à un usage. Sans cette étape, on passe du temps sur des détails visibles et on oublie parfois le chemin qui fait vivre le produit.

2. L’authentification

L’authentification répond à la question : qui est connecté ?

Je vérifie notamment la création de compte, la connexion, la réinitialisation du mot de passe, l’expiration des sessions et les accès d’administration. Un écran de connexion peut fonctionner tout en laissant subsister une ancienne session, une route non protégée ou un compte administrateur trop facile à atteindre.

Ce contrôle porte sur le serveur, pas seulement sur ce que l’interface affiche.

3. Les rôles et les permissions

Une fois la personne identifiée, il reste à décider ce qu’elle a le droit de voir et de modifier.

Le test utile consiste à changer d’utilisateur, d’organisation ou d’identifiant dans une requête. Si un client peut atteindre la facture, le dossier ou le profil d’un autre client, masquer le bouton dans l’interface ne règle rien.

La CNIL recommande de limiter les accès aux seules données nécessaires. Pour une application multi-utilisateur, ce principe doit être vérifiable dans le code et dans les requêtes vers la base.

4. Le modèle de données

Je regarde comment les principales informations sont reliées : utilisateur, organisation, abonnement, commande, dossier, historique.

Les problèmes apparaissent souvent quand deux noms désignent la même chose, quand une relation repose sur du texte libre ou quand supprimer un compte laisse des données orphelines. Le prototype peut encore fonctionner dans le cas nominal, mais chaque évolution devient plus risquée.

L’audit doit lister les incohérences qui menacent déjà un parcours ou une future migration. Un schéma redessiné n’aide que s’il répond à ces problèmes.

5. Les données personnelles

Quelles données sont collectées ? Où sont-elles stockées ? Qui peut les consulter ? Combien de temps restent-elles ?

L’audit ne remplace pas un conseil juridique. Il permet toutefois de repérer des décisions techniques qui rendent la conformité difficile : données réelles copiées dans un environnement de test, informations sensibles présentes dans les journaux, export impossible ou suppression qui ne supprime qu’une ligne visible.

Le guide de sécurité de la CNIL fournit un cadre utile sur les habilitations, la traçabilité, les sauvegardes et la gestion des incidents.

6. Les paiements et les états métier

Un paiement peut être refusé, retardé, remboursé ou confirmé après la fermeture de la page.

Un événement peut aussi être reçu plusieurs fois. Je vérifie donc ce qui fait foi : le retour affiché dans le navigateur, un événement du prestataire de paiement ou un état enregistré côté serveur.

Le même raisonnement s’applique aux invitations, aux envois d’emails et aux traitements longs. Dès qu’une action peut arriver en retard ou être rejouée, l’application doit savoir où elle en est.

7. Les services externes

Base de données, authentification, stockage, email, paiement, génération IA : un prototype moderne dépend vite de plusieurs services.

L’audit recense ces dépendances et vérifie qui possède les comptes, où sont stockées les clés, quelles limites s’appliquent et ce qui se passe si un service répond lentement. Ce travail révèle parfois qu’un compte personnel ou une carte bancaire privée tient toute la production.

La question n’est pas de supprimer chaque dépendance. C’est de savoir lesquelles peuvent arrêter le produit et comment reprendre la main.

8. Les erreurs et les cas limites

Une application fiable prévoit que tout ne se passe pas du premier coup.

Je teste les formulaires incomplets, les doubles clics, les fichiers trop lourds, les services indisponibles, les connexions interrompues et les actions répétées. Puis je regarde si l’utilisateur reçoit une réponse utile et si l’état du produit reste cohérent.

Une erreur bien affichée mais qui laisse une commande à moitié créée reste un problème.

9. Les tests

Le nombre de tests ne dit pas, à lui seul, si le produit est protégé.

Je cherche surtout les tests placés sur les règles difficiles à reconstruire : permissions, calculs, paiement, transitions d’état et parcours principaux. Un projet peut avoir beaucoup de tests d’interface et aucune protection sur la règle qui sépare les données de deux clients.

Quand il n’y a aucun test, l’audit identifie d’abord les quelques scénarios qui réduiraient réellement le risque de régression.

10. Le déploiement et les environnements

Qui peut mettre le produit en ligne ? À partir de quelle branche ? Avec quelles variables d’environnement ? Peut-on revenir à la version précédente ?

Je vérifie la séparation entre développement et production, la gestion des secrets, les migrations de base de données et les étapes qui reposent encore sur la mémoire d’une seule personne.

Un déploiement manuel n’est pas automatiquement mauvais. Il devient dangereux quand personne ne peut le reproduire ou l’annuler.

11. Les journaux, alertes et sauvegardes

Quand un utilisateur dit « ça ne marche plus », l’équipe doit pouvoir retrouver ce qui s’est passé.

Je vérifie les journaux d’erreurs, les alertes, le suivi des actions critiques et les moyens de restaurer les données. Une sauvegarde jamais restaurée reste une hypothèse. La CNIL recommande de tester régulièrement la disponibilité et l’intégrité des sauvegardes.

Il faut voir les incidents qui comptent et savoir revenir à un état exploitable. Le choix des outils vient ensuite.

12. La capacité à reprendre le projet

Dernier point : une autre personne peut-elle comprendre, lancer et modifier le projet sans dépendre d’une longue transmission orale ?

Je regarde la structure du dépôt, les instructions d’installation, l’historique Git, les dépendances, les conventions et les zones où plusieurs logiques se contredisent. C’est ici que l’on distingue un code imparfait mais reprenable d’un système dont chaque correction réveille un autre problème.

Cette analyse rejoint la décision détaillée dans reprendre ou refaire le code d’un projet Lovable.

Ce que l’audit doit livrer

Une liste de défauts ne suffit pas. À la fin, le fondateur doit obtenir :

• un état des lieux relié aux parcours du produit ;
• les risques classés par impact et urgence ;
• les preuves qui soutiennent chaque constat important ;
• un verdict sur ce qui peut rester, être corrigé ou être reconstruit ;
• une trajectoire chiffrée pour la suite.

Chez TechSprint, l’audit dure une semaine et coûte 2 k€. Le rapport reste au client, même si les corrections sont réalisées ailleurs. Pour situer le bon moment, relisez aussi les vérifications à faire avant de passer un prototype Lovable en production.

Quand l’audit n’est pas nécessaire

Continuez à prototyper si personne n’utilise encore l’application, qu’elle ne traite ni paiement ni donnée personnelle et qu’une panne n’a pas de conséquence commerciale.

Vous n’avez pas besoin d’un audit pour chaque nouvelle page. Il devient raisonnable quand le coût d’une erreur dépasse le coût du diagnostic : premier client, pilote, paiement, donnée sensible, recrutement ou échéance investisseur.

Si vous êtes à cette frontière, réservez un échange de 30 minutes avec TechSprint. Nous déterminerons d’abord si l’audit est utile dans votre situation.

Fabrice Payet — fondateur de TechSprint, La Réunion.