Faire relire le code livré par une IA avant la recette, est-ce une bonne idée ?

Attention, il y a un gros risque juridique ici. Que prévoient les clauses de confidentialité et de propriété intellectuelle du contrat signé avec l'agence ? Injecter le code propriétaire de l'entreprise dans une IA basée sur le cloud peut vous mettre en rupture de contrat sans que vous vous en rendiez compte. Si les données servent à l'entraînement sur des serveurs tiers, vous serez clairement en tort si ça se retourne contre vous.

Techniquement, la plus grande limite reste la fenêtre de contexte. Un système de gestion d'entrepôt à 26.000 EUR repose probablement sur des dizaines de services, un schéma de base de données complexe et des intégrations externes. Les modèles analysent les fichiers de façon isolée. Comme l'IA ne voit pas la validation de données effectuée trois fichiers plus loin, elle risque d'alerter pour rien en criant à la faille de sécurité.

En droit des contrats allemand, les vices doivent être documentés de manière concrète avant la signature du PV de réception. La sortie textuelle d'une IA n'est pas reconnue comme une notification de défaut valable. Il est impératif que le défaut soit reproductible sur l'environnement en fonctionnement et qu'il soit prouvé qu'il ne répond pas aux exigences du cahier des charges.

L'année dernière, on a fait exactement ça pour un portail B2B payé 18.000 EUR. Le modèle nous a sorti une liste de 47 points. Avant d'en parler à l'agence, on a payé un dev senior freelance 400 EUR pour vérifier. Sur les 47 points, seuls 4 étaient de vrais bugs, le reste c'était du vent. Par contre, l'un de ces 4 bugs pouvait complètement planter la prod. Bref : utile comme filtre, totalement insuffisant comme arbitre final.

au lieu de coller tout le code en mode "trouve-moi les bugs", fais plutôt module par module avec des consignes ciblées genre lister les dépendances et les failles de sécurité, t'auras un résultat bcp plus propre mais surtout envoie pas le texe brut de l'ia à l'agence ils vont pas te prendre au sérieux

Ne vous compliquez pas la vie. Basez votre recette directement sur l'expérience utilisateur et les fonctionnalités. Montez des scénarios de test : 1) Que se passe-t-il si on scanne un mauvais code-barres ? 2) La synchro des stocks est-elle maintenue en cas de coupure puis reprise d'Internet ? 3) Le système freeze-t-il à l'édition d'une facture ? Votre rôle n'est pas de juger la poésie du code, mais de vérifier qu'il fait le job pour votre activité.

Le contrat prévoyait-il des exigences sur les tests automatisés ou un taux de couverture de tests ? Et le dépôt livré contient-il des tests unitaires écrits par l'agence ? Si ces fichiers de test existent, les exécuter constitue un critère de recette bien plus net et incontestable que de faire mouliner le code dans une IA.

Un de nos clients avait fait un coup similaire. Il est arrivé en réunion en nous posant huit pages pondues par un prompt en disant "votre code c'est de la merde". L'un des points affirmait "mot de passe de base de données écrit en dur", alors que c'était juste un fichier d'exemple de config et que le vrai mot de passe venait d'une variable d'environnement. Ça a plombé l'ambiance et la livraison a pris deux mois de retard pour rien.

Ce qui est écrit correspond exactement à ce que nous avons vécu. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

J'espère que cela vous sera utile.

J'ai travaillé longtemps sur ce sujet. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

J'espère que cela vous sera utile.

Pour entrer dans le détail : Tous ceux qui se pressent sur prompt de revue de code se heurtent au même obstacle.

Chez nous, ça s'est passé comme ça. Plus il est difficile de revenir sur une décision plus il faut la prendre lentement.

Corrigez-moi si je me trompe.

Ce conseil ne convient pas à tout le monde, je pense. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Bien sûr, cela change si votre situation est différente.

Il y a un point que je ne comprends pas. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

La plupart des pertes de temps s'accumulent sur les tâches en attente de validation. Je suis aussi curieux de savoir si d'autres font autrement.

J'écris cela pour éviter que vous ne fassiez la même erreur. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Comment avez-vous résolu ce point ? Chaque « on verra ça plus tard » en réunion signifie du travail non chiffré.

Voilà, désolé si je me suis étendu.

Trois avis différents sont sortis, ils se complètent tous. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

Les décisions hâtives finissent par être corrigées six mois plus tard.

vous avez raison puis bon ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

bien sûr cela change si votre situation est différente.