DeepSeek corrige 3 bugs de 1C en 104 minutes et reproduit deux correctifs à l'identique

La mise à jour de 1C n'est pas encore sortie, et la comptabilité ne parvient déjà plus à valider un document. Une situation familière : l'erreur est cachée quelque part dans une immense configuration standard, il est interdit de la modifier directement, et le spécialiste doit d'abord démêler une longue chaîne d'appels. Dans cette expérience, on a confié quatre tâches de ce type à DeepSeek, en l'autorisant à lire l'export de la configuration, à accéder à une base de démonstration, à assembler des extensions et à vérifier le résultat dans l'interface de 1C.

Le résultat est plus instructif que le énième débat sur la question de savoir si l'IA remplacera le programmeur. L'agent a corrigé trois défauts ponctuels en 25 à 47 minutes, pour un coût de 155 à 427 roubles. Dans deux cas, son code était identique aux correctifs officiels de 1C. En revanche, sur une évolution plus importante, le modèle n'a livré qu'une solution fonctionnelle : elle marchait, mais l'architecture standard de 1C s'est révélée plus propre.

Comment l'agent a trouvé les erreurs

Dans le premier cas, l'impression du document de transfert universel (UTD) plantait avec une division par zéro lorsque la quantité de marchandise était inférieure à 0,005. La cause n'était pas une valeur initiale nulle. Le code arrondissait la quantité à deux décimales juste avant la division, transformant 0,001–0,004 en zéro. DeepSeek a trouvé la requête concernée dans un module d'environ 12 000 lignes, ajouté une protection et assemblé l'extension. Le correctif officiel résolvait le problème un peu différemment : il conservait trois décimales. L'agent a aussi remarqué que la description initiale de la limite du bug était imprécise.

Dans le deuxième cas, le paiement en ligne d'un bon de livraison n'était silencieusement pas chargé dans la base. Le gestionnaire commun attendait l'attribut « АдресСайта » (adresse du site), absent sur une partie des documents. Le modèle a ajouté une vérification de la présence de l'attribut avant d'y accéder. Cette solution coïncide totalement avec le correctif de 1C. L'agent a de plus découvert le même défaut dans deux autres types de documents, alors que la tâche initiale n'en parlait pas.

Le troisième bug se cachait dans le bouton de paiement via le SBP. Avec un compte bancaire vide, une faute de frappe dans un opérateur ternaire renvoyait une valeur booléenne au lieu d'une structure, et le code plantait lors de l'accès par point. DeepSeek a interrompu le scénario plus tôt et affiché un avertissement clair. Le plantage a disparu, mais le correctif officiel était plus précis : il corrigeait la faute de frappe elle-même et conservait la possibilité de sélectionner une connexion via l'agrégateur de paiement.

Là où le modèle a cédé face aux développeurs de 1C

La quatrième tâche n'était plus une réparation, mais une évolution produit : créer une fixation de prix à partir d'une commande fournisseur et ajouter un formulaire d'impression de réévaluation. L'agent a assemblé l'extension, branché les commandes et exécuté lui-même le scénario dans l'interface utilisateur. Il a même ajouté le pourcentage de variation du prix et une mise en évidence par couleur.

Cependant, le modèle connaissait moins bien les mécanismes de la Bibliothèque de sous-systèmes standard. Pour créer le document, il enregistrait d'abord un brouillon, et construisait le formulaire d'impression à la main. Les développeurs de 1C ont utilisé la saisie sur la base d'un document standard et l'impression standard avec export en PDF et Excel. La fonction était réalisée, mais la variante standard est plus simple à maintenir.

Ce qu'il faut retenir

La conclusion principale n'est pas que DeepSeek peut remplacer un développeur 1C. L'expérience ne le montre pas. Elle montre un scénario plus étroit et plus pratique : l'agent peut localiser rapidement un défaut, assembler une extension provisoire et la vérifier dans une interface vivante pendant que l'équipe attend la mise à jour de l'éditeur.

Une telle réparation ne doit pas être acceptée uniquement parce qu'elle ressemble au correctif officiel. Il faut une sauvegarde, une base de test distincte, la vérification du scénario métier et la possibilité de désactiver instantanément l'extension. Pour les pannes ponctuelles, le modèle apparaît déjà comme un partenaire utile. Pour les évolutions architecturales, il lui faut encore un spécialiste qui connaît la plateforme et arrêtera une solution qui fonctionne, mais qui est fragile.