Vision dans Azure : de décrire une image à générer une vidéo

Jusqu'ici, le modèle avec lequel vous parliez ne comprenait que le texte ; « Introduction to Computer Vision in Azure » sur Microsoft Learn montre que la même porte d'entrée (l'API de responses de Foundry) accepte aussi des images et renvoie des illustrations et des clips vidéo. Le parcours va en ordre de complexité croissante : d'abord analyser ce que la caméra voit, ensuite générer des images, et seulement à la fin allumer le rendu vidéo, qui est un autre rythme parce qu'il tourne comme un travail asynchrone. Ce post suit ces trois capacités et montre où vit chaque modèle et comment chacune s'appelle depuis le code.

Trois capacités, une même porte

Le parcours a trois mouvements et un seul point d'entrée. L'API de responses de Foundry que vous utilisiez déjà avec le texte accepte maintenant une image ; et sur la même base apparaissent deux générateurs de plus, un qui dessine et un qui rend. La carte, en un diagramme :

flowchart LR
    T[Votre texte ou votre image] --> A[Analyser<br/>modèle multimodal · input_text + input_image]
    T --> G[Générer des images<br/>famille GPT-Image · image_generation]
    T --> V[Générer une vidéo<br/>Sora · travail asynchrone avec sondage]

Chaque branche a sa propre forme d'appel et sa propre cadence : celle d'analyse se résout en une seule requête, celle de l'image renvoie des octets à décoder, et celle de vidéo laisse un travail en cours qu'il faut surveiller.

Faire voir aux machines

Computer Vision est le champ d'IA qui permet aux machines d'interpréter et de comprendre l'information visuelle du monde (images, vidéos, flux de caméra en direct) pour identifier et analyser des objets, reconnaître des motifs, lire le texte dans les images et interpréter des scènes. Les applications industrielles, sanitaires, commerciales et de transport se reconnaissent instantanément : détection de défauts en fabrication, analyse d'images médicales, surveillance de rayonnages et véhicules autonomes. Du côté plus quotidien, la même technologie couvre depuis la recherche d'images et l'analyse de documents jusqu'aux outils créatifs et aux expériences interactives. Ce qu'elle automatise, c'est du travail répétitif qui prend du temps : regarder chaque pièce d'une ligne d'assemblage, vérifier des radiographies, surveiller un rayon, reconnaître un panneau. Dans les quatre, la machine remplace un regard qu'une personne fait des milliers de fois par jour.

Un modèle qui regarde et écrit

Un modèle multimodal comprend et travaille avec plus d'un type de données à la fois (texte, images, audio ou vidéo). En acceptant texte et image dans la même requête, il réduit le besoin de pipelines de vision indépendants et permet de créer des expériences intelligentes de bout en bout sans connaissances approfondies en Computer Vision. Cette capacité à combiner compréhension visuelle et réponse en langage naturel est ce qu'on appelle GPT avec vision ou modèles habilités à la vision.

En une seule requête le modèle fait trois choses différentes : décrit l'image, répond à des questions sur ses objets, son texte ou ses scènes, et extrait la signification des graphiques, captures et documents. Tout avec la même instruction de texte, sans changer de modèle ni d'étape intermédiaire.

Dans le catalogue de Foundry, pour l'analyse d'images l'offre s'ordonne ainsi : GPT-4.1, sa version mini et sa version nano pour la description et la réponse visuelle ; la série GPT-5 (entrées bidirectionnelles, sorties structurées, usage d'outils et raisonnement à grand contexte) pour les agents de production ; et des modèles de partenaires comme Anthropic quand on cherche une autre signature de modèle. La question pratique en est une autre : combien de latence, de contexte et de structure de sortie l'app a besoin.

Comment une image s'envoie

L'API de responses d'Azure OpenAI est conçue pour les applications agentic et admet des entrées multimodales natives : en une seule requête le texte et l'image voyagent ensemble, donc aucune étape préalable de vision par ordinateur n'est nécessaire. L'envoi est un message multi-parties avec un élément de texte (input_text) et un élément d'image (input_image) dont l'URL pointe vers l'image, qui peut aussi arriver comme données encodées en base64 ; le modèle traite les deux entrées simultanément. Conceptuellement, le prompt est une instruction de texte plus une ou plusieurs images jointes. Et base64 convertit des données binaires en texte ASCII sûr pour pouvoir les imbriquer dans du JSON ou une URL.

Avant d'écrire du code, l'essai rapide est dans le playground de Foundry : vous chargez l'image, écrivez ce que vous voulez savoir et lisez la réponse. Si elle ne décrit pas bien ce dont vous avez besoin là, le problème est dans la demande et pas dans l'intégration ; le résoudre avant de programmer économise tout le cycle de déboguer un script qui échoue seulement à la description.

Le schéma de départ est un appel à responses.create avec un message de rôle user dont le contenu combine input_text ("What is in this image? Provide 3 bullet points.") et input_image avec l'URL de l'image, et une lecture de response.output_text. Une variation du même schéma résout l'identification d'animaux en safari : un fichier Python se connecte au point de terminaison du modèle dans Foundry, charge les données de l'image, reçoit un message en langage naturel et crée un message multi-parties avec image et texte pour que le modèle réponde. Dans les deux cas, l'app cliente est un script court sur le SDK openai (kit de développement logiciel) pointé vers le point de terminaison de la ressource Foundry : authentification avec la clé, message multimodal, texte de sortie. Les deux seules lignes qui changent face à un chat de pur texte sont celles qui assemblent le message avec l'image et celles qui lisent la réponse.

Générer des images : la famille GPT-Image

La génération vit dans la famille GPT-Image. GPT-Image-1.5 est le modèle le plus récent, pour la création et l'édition d'images de niveau entreprise avec alignement rapide et cohérence entre itérations (texte vers image, image vers image et édition précise). GPT-Image-1 est le modèle d'usage général héritier de DALL-E, avec une large compatibilité avec les outils et l'API de Foundry. GPT-Image-1-Mini est plus léger et moins cher, pour quand la latence ou le coût pèse plus que la fidélité maximale. Microsoft recommande de commencer par GPT-Image-1, en particulier GPT-Image-1.5, dans la plupart des nouveaux projets, et les trois admettent texte vers image, variantes et édition précise. En pratique, ils se déploient dans une ressource Foundry et se testent dans le playground ; depuis le code ils s'appellent avec l'API de responses ou les API d'images.

Dans le code, le flux est direct. Il faut une ressource Foundry, un déploiement de modèle compatible avec la vision (son nom est ce qui passe en MODEL_NAME) et une authentification avec clé d'API ou identifiant Microsoft Entra. L'appel à responses.create inclut l'outil image_generation, et le résultat se récupère en base64 pour le décoder et l'enregistrer en fichier image. Concrètement : responses.create(model=..., input=prompt, tools=[{"type": "image_generation"}]) renvoie dans response.output un élément image_generation_call dont le champ result est en base64, et base64.b64decode(...) écrit le .png. En clair : un prompt texte entre, un fichier image sort, et la seule étape que le code doit faire de son côté est de décoder. Il y a aussi des modèles tiers comme FLUX disponibles dans le catalogue pour qui veut comparer.

Générer une vidéo : Sora et le travail asynchrone

Sora 1 convertit le texte en clips courts (admet aussi des images en entrée), avec plusieurs résolutions et durées, exposé dans le service Azure OpenAI et le Foundry Video Playground. Sora 2, en préversion publique, ajoute texte vers vidéo, image vers vidéo et vidéo vers vidéo avec remix, génération d'audio, réalisme amélioré et remixer ciblé sans régénérer la vidéo complète. Ce sont les seuls modèles natifs de génération de vidéo de Foundry, et tous deux incluent des restrictions d'IA responsable : limites sur les personnes réelles, les personnages protégés par le droit d'auteur et les types de contenu.

La génération de vidéo consomme beaucoup de ressources et s'exécute comme travail asynchrone, donc le schéma change par rapport aux appels précédents : vous n'attendez pas la réponse, vous laissez un travail et vous le surveillez.

flowchart LR
    P[POST /videos<br/>crée le travail] --> S{Statut ?}
    S -- pending --> S
    S -- completed --> D[GET content<br/>télécharge le MP4]
    S -- failed --> X[Échec du rendu]

L'API de Sora 2 expose des points de terminaison différents pour lancer le rendu, sonder le statut et télécharger le contenu, et les trois étapes sont :

POST /openai/v1/videos avec model, prompt, size et seconds renvoie un identifiant.
GET /openai/v1/videos/{video_id} est sondé jusqu'à ce que le statut soit completed (ou failed).
GET .../content?variant=video télécharge le MP4.

Tout avec un en-tête api-key. Il faut une ressource Azure OpenAI/Foundry dans une région admise avec un déploiement Sora, et une clé d'API ou un identifiant Microsoft Entra. Les durées sont en général de 1 à 5 minutes selon la configuration (minutes, pas secondes), donc il vaut la lancer en arrière-plan et sonder le statut. Le MP4 ne se télécharge que quand le travail est fini, donc pendant qu'il rend, vous passez à autre chose.

Quoi choisir, résumé

Si le problème tombe dans une de ces trois portes, le modèle est un de trois : l'image qu'il faut comprendre va à un modèle multimodal avec ses input_text et input_image ; l'image qu'il faut produire va à la famille GPT-Image (1.5 si la qualité et l'édition sont la priorité, 1 s'il faut de la compatibilité, Mini si la latence ou le coût pèsent) ; et le clip qu'il faut rendre va à Sora (1 pour le clip texte vers vidéo, 2 s'il faut du remix ou de l'audio). Les trois portes partagent la même autorisation (clé d'API ou identité Microsoft Entra) et la même ressource Foundry en dessous, donc en apprendre une sert pour les deux autres. Et si ce qui sortira est une vidéo, rappelez que le rendu est un travail avec son propre identifiant : chaque video_id se sonde et se télécharge séparément.

De la lecture à l'exécution

La pratique avec des modèles d'IA générative et des données visuelles est restée en lecture : sa description a été relue, mais pas exécutée. Ce que ce parcours rend clair, c'est la carte (quel modèle regarde, quel modèle dessine, quel modèle rend, et comment chaque moyen arrive à la même API) ; ce qui manque à tester sur un abonnement à soi, c'est le flux complet de génération, parce qu'il exige des déploiements déployés et de vraies ressources côté Azure, pas seulement de lire dessus.

---

*Source : le module « Introduction to Computer Vision in Azure » de Microsoft Learn.*