Chaque responsable de l'ingénierie se retrouve à un moment ou à un autre dans une situation difficile : est-ce que nous la construisons nous-mêmes ou est-ce que nous achetons une plateforme qui fonctionne déjà ? Avec l'explosion des API d'IA, il semble plus facile que jamais de créer. Google, OpenAI et d'innombrables autres proposent désormais tout, de la génération de texte à la génération d'images en passant par la synthèse vidéo. En outre, un nombre croissant d'outils low-code donnent l'impression qu'il est d'une simplicité trompeuse de connecter ces API à votre propre « plateforme interne ».
Pour automatisation de l'image et de la vidéo, cette tentation est particulièrement forte. Après tout, à quel point peut-il être difficile de connecter quelques API, de traiter certains médias dans le cloud et d'intégrer les résultats à votre CMS ou à votre plateforme de commerce électronique ?
Il s'avère que la réponse est la suivante : plus difficile qu'il n'y paraît.
La tentation de construire
Un grand détaillant de l'UE a récemment dû faire face à cette décision. Leur équipe des opérations informatiques, à l'aise avec les API cloud, a décidé de créer une application interne qui générerait automatiquement imagerie du produit et court vidéos de produits à l'aide des API Vision et Video Intelligence de Google. L'objectif était simple : automatiser leur pipeline d'images de page détaillée du produit (PDP) et réduire les coûts liés à l'utilisation des services SaaS.
Le prototype a parfaitement fonctionné. Quelques scripts rapides ont produit des visuels impressionnants. Encouragée, l'équipe a décidé d'héberger une petite interface Web afin que le personnel marketing non technique puisse la gérer lui-même.
C'est alors que la complexité a commencé à faire boule de neige.
Même si le traitement multimédia s'est fait dans le cloud, ils ont tout de même dû héberger et gérer l'application Gen AI lui-même. Les mises à jour apportées aux bibliothèques Python ont supprimé les dépendances. Les clés d'API ont expiré. L'application nécessitait une authentification, des limites d'utilisation et une journalisation. Puis sont venues les demandes de fonctionnalités émanant du marketing. « Pouvons-nous rendre la génération d'arrière-plan (en termes techniques) plus contextuelle en fonction de nos catégories de produits ? » , « Pouvez-vous générer une version avec des spirales avec une vue à 360 degrés ? »
Très vite, l'équipe des opérations informatiques s'est retrouvée à agir comme un studio de création, à recueillir des commentaires sur la conception et à essayer de modifier les instructions. Pour que l'outil soit utilisable par des collègues du marketing non spécialisés, ils devaient exposer des commandes ajustables et créer une interface utilisateur autour de celles-ci. Cette interface utilisateur est devenue un projet à part entière.
Voici le type de code Python qui a tout déclenché : un petit script inoffensif qui s'est transformé en un produit que personne n'avait prévu de maintenir :
depuis google.cloud, importez videointelligence_v1 en tant que vi
client = VI.VideoIntelligenceServiceClient ()
fonctionnalités = ["LABEL_DETECTION"]
opération = client.annotate_video (
demande= {
« fonctionnalités » : fonctionnalités,
« input_uri » : « gs : //retailer-assets/shoe_video.mp4 »
}
)
résultat = operation.result (timeout=300)
pour l'annotation dans result.annotation_results [0] .segment_label_annotations :
imprimer (annotation.entity.description)
L'extrait semble simple. En production, cela nécessitait une gestion des erreurs, de nouvelles tentatives, une mise en file d'attente des tâches, une authentification et un tableau de bord interne. En 6 mois, leur « script d'automatisation » ressemblait davantage à un produit logiciel, un produit que le service informatique devait désormais prendre en charge.
Les coûts cachés
Lorsque vous retirez les couches, la création de votre propre système d'automatisation de l'image entraîne des coûts que la plupart des équipes sous-estiment.
Même si les appels d'API eux-mêmes ne coûtent pas cher, disons 0,05 dollar par image ou 0,50 dollar par vidéo de 6 secondes, le coût caché réside dans les personnes chargées de la maintenance, les réunions sur les modifications des fonctionnalités et l'arriéré croissant d' « améliorations mineures ». Les dirigeants du détaillant se sont rendu compte qu'ils exploitaient un produit SaaS interne sans le vouloir.
L'un des plus grands détaillants indiens l'a dit plus franchement. Leur responsable du numérique nous a dit : « Nous voulions automatiser le traitement des images, pas devenir le département créatif. »
C'est un sentiment que partagent aujourd'hui de nombreuses équipes informatiques. La frontière entre l'infrastructure d'ingénierie et la production créative est facile à brouiller une fois que l'IA entre dans le flux de travail.
Acheter une plateforme spécialement conçue
Imaginez maintenant que le même détaillant choisisse un itinéraire différent. Au lieu de construire à partir de zéro, ils adoptent une culture. Photo comme une plateforme SaaS avec des recettes d'automatisation pour leurs images PDP et leurs vidéos de produits.
Ils bénéficient toujours de l'accès à l'API et du contrôle de l'automatisation, mais sans entretenir l'échafaudage qui les entoure. Chaque flux de travail peut être enregistré en tant que recette réutilisable avec une mémoire contextuelle, ce qui signifie que le système mémorise les paramètres précédents, les directives de la marque et les préférences visuelles. Chaque nouveau lot d'images est exécuté avec des styles cohérents, conformes à la marque.
Les détaillants accordent une grande importance à ces détails subtils. Une légère variation de couleur sur l'image d'un sac à main ou un éclairage incohérent entre les variantes peuvent avoir un impact sur les taux de conversion. Une plateforme d'automatisation telle que Crop.photo garantit que ces écarts restent dans les limites des seuils acceptés par la marque.
Le système gère également les problèmes les plus difficiles auxquels les équipes internes ont dû faire face : les nouvelles tentatives échouées, le traitement par lots à l'échelle industrielle et l'optimisation automatique pour les places de marché qui imposent des limites strictes en termes de taille ou de format de fichier. Le résultat est un système d'IA qui agit comme un assistant créatif : rapide, prévisible et fiable.
Le calcul du retour sur investissement
Pour un CXO, l'argument le plus convaincant n'est pas la commodité. Il s'agit d'un retour sur investissement (ROI).
Regardons une chronologie typique.
- Tracé de construction : 6 à 9 mois avant le titre de MVP. Première version utilisable vers le mois 4. La maintenance commence immédiatement après.
- Parcours d'achat : Test et déploiement du POC en moins de 2 à 4 semaines.
Avec un coût annuel de 110 000 dollars par ingénieur, même une petite équipe de construction composée de deux personnes coûte près d'un quart de million de dollars par an avant le traitement d'une seule image. En revanche, une plateforme d'automatisation commerciale telle que Crop.photo offre tarification prévisible, par image/vidéo qui peuvent être intégralement comptabilisés en tant que coût d'exploitation plutôt qu'en tant qu'investissement d'ingénierie capitalisé.
Lorsque les directeurs financiers comparent les périodes d'amortissement, le calcul est unilatéral. La version interne peut sembler bon marché au début car les appels d'API sont peu coûteux. Mais au moment où la première demande de fonctionnalité arrive, ou lorsque la première mise à jour du modèle rompt la rétrocompatibilité, la charge de maintenance efface cet avantage.
La période de récupération des achats est généralement mesurée en semaines, et non des années, car il n'y a pas de coûts d'ingénierie irrécupérables ni de charge de support interne.
Un cadre de décision simple
Alors, quand est-il judicieux de construire ?
Si votre volume est extrêmement faible et qu'il s'agit d'un projet ponctuel, peut-être. Mais même dans ce cas, les coûts de configuration, de débogage et d'hébergement l'emportent sur les économies réalisées.
Pour presque tous les cas d'utilisation durables - Images PDP, des mises à jour du catalogue, des vidéos de campagne : la décision penche en faveur de l'achat. C'est la même évolution que les équipes d'entreprise ont connue il y a dix ans avec les logiciels CRM et d'automatisation du marketing. Vous pourrait assemblez des outils open source pour créer votre propre CRM. Mais le ferais-tu aujourd'hui ?
Ce que vous choisissez vraiment, c'est le maintien les processus ou en maintenant résultats. Construire signifie maintenir le processus : gestion du code de version, gestion du support, gestion de la disponibilité. Acheter signifie préserver les résultats, c'est-à-dire garantir des actifs créatifs cohérents et conformes à grande échelle.
Et les résultats sont ce que l'entreprise voit réellement.
L'objectif du CTO
En tant qu'ingénieurs, il est facile de sous-estimer la complexité des composés qui s'insinue au fil du temps. Le premier prototype semble stimulant ; le dixième rapport de bogue ressemble à du déjà vu. Chaque outil interne finit par se comporter comme un produit, et chaque produit a besoin d'une équipe.
Pour l'automatisation des images, le calcul est simple. Le contrôle est satisfaisant, mais la maintenance est coûteuse. Si votre objectif est d'assurer une cohérence créative, et non de gérer un Société de logiciels d'IA au sein de votre service informatique, les achats sont gagnants à chaque fois.
La véritable prouesse technique n'est pas d'écrire plus de code. C'est écrire moins de code qui apporte plus de valeur.
C'est l'avenir de l'automatisation intelligente de l'IA de génération : moins de scripts, plus de résultats et aucun regret lors de la prochaine mise à jour du modèle.
