---
suivi: 1361
date: 2026-08-19
sujet: ocr_non_bloquant
chantier: depot_factures
type: fix
statut: poussé
hash: 811d5b49
fichiers:
  - app/Http/Controllers/DepotFactureController.php
  - app/Services/DepotFactureClaudeAnalysisService.php
  - app/Services/OcrFactureService.php
  - app/Listeners/LogOutboundHttpCall.php
  - database/data/journal_mises_a_jour_post_2026_06_12.php
  - docs/suivi/SUIVI_1361_ocr_non_bloquant.md
---

## PROMPT ENVOYE

Rendre l'OCR Anthropic non bloquant sur le depot de factures, avec timeout court
explicite, seuil d'arret de lot apres 2 echecs consecutifs, aucune boucle de retry,
ventilation des logs de consommation OCR vs assistant, et plafonnement des alertes OCR.

## FICHES LUES

- `#1276` — depots: verrouiller les regressions sur circuit de validation.
- `#1352` — widget depot re-utilise les memes endpoints.
- `#1360` — structure de livrable et lessons recentes.

## SYNTHESE

### Objet 2 — Degradation propre OCR

- Timeout explicite ajoute sur OCR depot (`connect=2s`, `total=6s`).
- Suppression de `Http::withoutVerifying()` sur les appels Anthropic OCR.
- En echec OCR: depot conserve en `STATUT_DEPOSE`, `ocr_erreur` renseigne,
  formulaire ouvrable, saisie manuelle intacte.
- Message utilisateur inchange: depot termine avec avertissement sobre.

### Objet 3 — Maitrise cout / pas de boucle

- Aucun retry automatique ajoute (ni sur 429/529, ni ailleurs).
- Seuil d'arret de lot: au 2e echec OCR consecutif dans `store()`, circuit ouvert.
- PDFs restants du lot: depot cree sans nouvel appel Anthropic, marquage
  `ocr_erreur` explicite, reanalyse possible via bouton existant.
- Plafond alertes OCR sur lot: une seule alerte utilisateur max par appel `store()`.
- Logs API sortantes: operation OCR forcee via contexte (`api_operation`),
  ce qui separe OCR facture (`depot_facture_ocr` / `facture_ocr_assist`) des appels
  assistant, tout en conservant tokens + cout estime par appel.

### Limite connue de temps (utile pour l’arbitrage)

- Timeout OCR Anthropic retenu : `connect=2s` et `total=6s` par PDF.
- Pire cas "panne franche" sur lot : on exécute 2 appels OCR consécutifs puis on
  ouvre le circuit. Donc ~`2 × 6s = 12s` (hors overhead application).
- Cas "API lente mais fonctionnelle" : si aucune analyse ne tombe en echec
  (pas 2 erreurs consécutives), le circuit ne s’ouvre pas et on peut attendre
  jusqu’a ~`10 × 6s = 60s` sur le lot max.
- Marge production web : `.user.ini` OVH fixe `max_execution_time = 300` (300s),
  donc le cas pire (60s) reste sous ce plafond web. Le dépassement ne doit pas
  arriver si les timeouts OCR sont respectés.

### Verifications techniques

- `curl -I https://api.anthropic.com/v1/messages` renvoie `HTTP/1.1 405`
  (handshake TLS OK): verification certificat operationnelle sans `withoutVerifying`.
- `git log -S"withoutVerifying()->withHeaders"` sur
  `DepotFactureClaudeAnalysisService.php` montre l'introduction au commit `ec29db9e`.

## DEPLOIEMENT-TEST

```bash
git pull origin main
php artisan optimize:clear
php artisan view:clear
php artisan journal:sync
```

Procedure Robin (prod, test manuel):
1. Couper temporairement la cle OCR (ou forcer endpoint indisponible) et deposer 3 PDF:
   les 3 depots existent, PDFs presents, formulaire ouvrable.
2. Verifier qu'apres 2 echecs consecutifs le 3e depot est cree sans nouvel appel OCR.
3. Cliquer "Analyser avec Claude" sur un depot non analyse: reanalyse sans reupload.
4. Verifier `/admin/api-logs`: operations `depot_facture_ocr` vs assistant distinguees,
   tokens et cout par appel visibles.
5. Verifier apres deploiement:
   `grep "production.ERROR" storage/logs/laravel.log | tail -20`.

## LECON

Sur un flux comptable critique, un service externe d'aide (OCR) doit toujours etre
degrade proprement: temps borne, pas de retry en cascade, et interruption preventive
du lot pour eviter cout et latence inutiles.

### Precision TLS — autres usages de `Http::withoutVerifying()`

- Suppression faite uniquement sur les appels OCR facture :
  - `DepotFactureClaudeAnalysisService` (messages Anthropic OCR)
  - `OcrFactureService` (endpoint /messages utilise par l'autre flow)
- Inventaire : les autres appels HTTP sortants qui contiennent encore
  `Http::withoutVerifying()` dans le code actuel :
  - `app/Services/GraphApiService.php` (Graph MS)
  - `app/Http/Controllers/Admin/GraphMailTestController.php` (test Graph)
  - `app/Services/Assistant/AssistantAnthropicService.php` et
    `app/Services/Assistant/AssistantConsolidationAgentService.php` (Anthropic assistants)
  - `app/Services/SharePointService.php` (SharePoint)
  - `app/Services/OutlookAttachmentService.php` (Outlook)
  - `app/Services/NfHabitatClaudeExtractionService.php` (Anthropic / NfHabitat)
  - `app/Services/LeadsMarketingSharePointFieldsTester.php` (test SharePoint)
- Note Intacct / Meta : scan `Http::withoutVerifying()` → aucune occurrence dans
  les services Intacct et Meta. Donc un retrait équivalent nécessiterait une
  validation TLS dédiée par connecteur (sans modification ici).