La plupart des projets de vision qui échouent disposaient d’un budget suffisant, d’une équipe compétente et d’un modèle performant. Ce qui manquait se situait ailleurs, et se voyait dès les premières semaines pour qui savait regarder.
Cet article expose ces causes. Il prolonge l’article consacré au budget d’un projet.
Ce que le cadrage manqué produit
Cinq défauts initiaux condamnent un projet de computer vision.
Un besoin exprimé sans que la décision attendue ne soit jamais écrite.
Un seuil d’acceptation jamais fixé dès le départ.
Une tâche retenue sans le moindre examen des données disponibles.
Un coût des erreurs jamais chiffré par les équipes métier.
Et des contraintes de déploiement ignorées jusqu’à la fin.
Une conséquence pratique importante en découle. Le deuxième défaut rend le projet inachevable, un système ne pouvant être ni validé ni abandonné faute de référence convenue.
Ce que le corpus mal composé entraîne
Cinq faiblesses de données produisent un échec tardif en computer vision.
Des images soigneusement sélectionnées parmi les mieux réussies.
Une absence complète de toutes les conditions dégradées.
Des cas critiques représentés par une poignée d’exemples.
Un décor associé systématiquement à une seule catégorie.
Et un jeu de test extrait exactement du même lot que l’entraînement.
Une observation importante en découle pour un projet de computer vision. La dernière faiblesse masque toutes les autres, une évaluation flatteuse empêchant de découvrir les quatre premières avant la mise en service.
Ce que l’écart au terrain révèle
Cinq différences séparent le laboratoire de l’usage réel.
Un matériel d’acquisition différent de celui ayant produit le corpus.
Un éclairage variable là où les essais restaient parfaitement stables.
Une distribution des situations tout autre que celle prévue.
Un temps de réponse insuffisant sur le matériel cible.
Et des sorties incompatibles avec le système chargé de les recevoir.
Une conséquence pratique s’ensuit. Ces cinq différences se découvrent toutes au même moment, ce qui transforme la mise en service en révélation générale plutôt qu’en formalité.
Ce que la démonstration réussie masque
Cinq écarts séparent une démonstration d’un système en service.
Les images montrées ont toutes été choisies parmi les plus favorables.
Le matériel employé diffère nettement de celui du site réel.
Le volume traité reste sans commune mesure avec l’usage.
Aucune contrainte réelle de temps de réponse ne s’applique alors.
Et personne ne vérifie ce que le système a manqué.
Une observation importante en découle pour un projet de computer vision. Le dernier écart rend une démonstration presque toujours convaincante, un système montrant ce qu’il détecte sans jamais montrer ce qu’il laisse passer.
Ce que l’absence d’adoption signale
Cinq raisons expliquent qu’un système de computer vision livré ne serve jamais.
Un taux de fausses alertes incompatible avec le rythme de travail réel.
Une intégration exigeant un détour permanent dans les habitudes.
Une absence de bénéfice visible pour ceux qui l’emploient.
Une perception du dispositif comme un simple moyen de contrôle.
Et une impossibilité de corriger ou bien d’ignorer une proposition faite.
Une observation en découle. La troisième raison décide plus souvent que la performance technique, un système techniquement parfait mais sans intérêt pour ses utilisateurs étant contourné dès les toutes premières semaines.
Ce que la dérive silencieuse produit
Cinq changements dégradent un système de computer vision sans aucune alerte.
Un capteur remplacé par un modèle voisin mais légèrement différent.
Un éclairage modifié par des travaux ou bien par la saison.
Des objets observés évoluant peu à peu dans leur apparence.
Une catégorie entièrement nouvelle apparaissant dans le flux réel.
Et des optiques encrassées que plus personne ne songe à nettoyer.
Une conséquence pratique importante en découle pour un projet de computer vision. Ces cinq changements n’émettent aucun signal, une performance déclinant lentement sans qu’aucun indicateur ne se déclenche tant qu’un suivi n’a pas été explicitement mis en place.
Aborder le risque d’échec
Cinq questions cadrent le risque d’échec d’un projet de computer vision.
Le seuil visé est-il écrit. Sinon plus rien ne conclut.
Le corpus vient-il vraiment du terrain. Souvent non.
Le jeu de test est-il séparé. Il doit l’être en premier.
Les utilisateurs y gagnent-ils. Sinon ils le contourneront.
Et la dérive est-elle suivie. Rien d’autre ne la signale.
Ces cinq réponses déterminent la solidité d’un projet. Les poser au départ évite un échec que personne ne saura expliquer.
Ce que ce chapitre enseigne
Une observation transversale mérite de clore cet examen.
Les projets échouent au cadrage et le découvrent au déploiement.
Trois constats la composent.
Un seuil jamais écrit rend le projet impossible à conclure.
Un jeu de test mal séparé finit par masquer tous les autres défauts.
Et un système sans bénéfice pour ses utilisateurs finira par être contourné.
Ce constat prolonge les chapitres précédents, la difficulté se situant rarement là où l’attention se porte.
Les erreurs les plus fréquentes
- Lancer un projet sans le moindre seuil d’acceptation écrit.
- Constituer le corpus à partir des seules meilleures images disponibles.
- Extraire le jeu de test exactement du même lot que l’entraînement.
- Ignorer entièrement les conditions matérielles du déploiement prévu.
- Négliger le taux de fausses alertes réellement acceptable en exploitation.
- Concevoir un système sans aucun bénéfice pour ses utilisateurs.
- Omettre tout dispositif de suivi une fois la mise en service faite.
- Découvrir le format de sortie attendu tout en fin de projet.
- Traiter la mise en service comme une simple formalité.
- Attribuer un échec au modèle plutôt qu’au cadrage initial.
Ce que l’organisation du projet révèle
Cinq signaux annoncent une difficulté avant qu’elle n’apparaisse.
Aucun interlocuteur métier réellement disponible pour les arbitrages.
Un projet porté par la seule technique sans commanditaire clair.
Des utilisateurs finaux jamais consultés sur le besoin réel.
Une équipe technique privée d’accès aux conditions réelles du site.
Et un calendrier fixé bien avant tout examen des données.
Une conséquence pratique importante en découle pour un projet de computer vision. Le troisième signal explique une part importante des échecs d’adoption, un dispositif conçu sans ceux qui l’emploieront répondant rarement au problème qu’ils rencontrent réellement.
Ce que le moment de l’échec indique
Cinq étapes révèlent chacune un type de défaut différent.
Un échec dès le premier lot signale un référentiel resté ambigu.
Un échec au moment de l’évaluation signale un corpus insuffisant.
Un échec lors du portage signale une contrainte matérielle ignorée.
Un échec à la mise en service signale un écart avec le terrain.
Et un échec après quelques mois signale une dérive non suivie.
Une observation importante en découle pour un projet de computer vision. Ces cinq moments permettent de remonter à la cause sans enquête longue, la date de l’échec désignant assez précisément l’étape où la décision manquante aurait dû être prise.
Trois décisions pour réduire le risque
Trois décisions protègent un projet de computer vision.
Écrire le seuil d’acceptation avant tout développement.
Constituer le jeu de test à partir des conditions réelles d’usage.
Et associer les futurs utilisateurs dès la phase de cadrage.
Ces trois décisions coûtent quelques jours, elles précèdent toute production, et leur absence explique la majorité des échecs constatés.
La question qui distingue les échecs
Une question sépare deux catégories d’échec en computer vision.
Le système fonctionne-t-il mal ou fonctionne-t-il sur le mauvais problème.
Fonctionnant mal, un corpus insuffisant ou un modèle inadapté, se corrige par un complément de données ou un travail technique supplémentaire.
Portant sur le mauvais problème, une décision mal définie ou un usage mal compris, ne se corrige par aucun effort technique et impose de reprendre le cadrage.
Cette question se tranche en examinant les erreurs constatées, elle se pose dès les premiers signes de difficulté, et elle évite des mois consacrés à améliorer ce qui ne servira pas.
Trois vérifications sur un projet en difficulté
Trois contrôles orientent un diagnostic de computer vision.
L’existence d’un seuil d’acceptation écrit avant le démarrage.
La provenance réelle des données du jeu de test employé.
Et la présence des utilisateurs finaux dans la définition du besoin.
Ces trois contrôles se posent en une question chacun, ils ne demandent aucune compétence technique, et leur absence explique généralement la difficulté rencontrée.
Ce que le prestataire de données apporte ici
Quatre apports réduisent le risque avant qu’il ne se matérialise.
Un examen attentif des données disponibles avant tout engagement.
Un signalement de toutes les situations que le corpus ne couvre pas.
Un jeu de test constitué indépendamment du corpus d’entraînement.
Et une alerte claire lorsque le seuil visé paraît hors d’atteinte.
Une conséquence pratique importante en découle. Le dernier apport demande le plus de courage et évite le plus de dépense, un projet arrêté à temps coûtant infiniment moins cher qu’un projet mené jusqu’à un échec que personne n’osait annoncer.
Ce que l’attribution des causes déforme
Cinq explications reviennent après un échec et désignent rarement la cause.
Le modèle finalement employé n’était pas le bon.
Le volume de données disponible restait insuffisant.
La technologie elle-même n’était pas encore mûre.
Le prestataire n’a pas tenu ses engagements.
Et les utilisateurs finaux se sont montrés réticents.
Une observation importante en découle pour un projet de computer vision. Ces cinq explications déplacent la responsabilité vers l’exécution alors que la décision manquante se situait presque toujours au cadrage, ce qui garantit de reproduire le même échec au projet suivant.
Ce que ce chapitre laisse au suivant
Éviter ces échecs suppose de savoir avec quoi travailler.
Trois questions restent ouvertes en computer vision.
Quels outils existent et ce qu’ils permettent réellement.
Ce que reprendre un composant existant engage à long terme.
Et où se situe la frontière entre gratuit et coûteux.
Ces trois questions relèvent de l’open source en vision, qui constitue l’objet du chapitre suivant.
Trois erreurs qui reviennent partout
Trois défauts de computer vision se retrouvent dans presque tous les échecs.
Un objectif de performance fixé sans référence au coût des erreurs.
Un corpus constitué à partir de ce qui était disponible.
Et un déploiement abordé comme une étape de fin de projet.
Ces trois défauts se commettent par des équipes expérimentées, ils échappent à toute revue technique, et leur point commun est de porter sur des décisions que personne ne considère comme techniques.
Ce que le client peut faire échouer seul
Cinq comportements côté commanditaire suffisent à condamner un projet.
Transmettre un échantillon soigneusement choisi plutôt que les données réelles.
Rester durablement indisponible pour trancher les cas ambigus rencontrés.
Modifier les catégories attendues en pleine phase de production.
Refuser de chiffrer le coût respectif des deux types d’erreur.
Et découvrir les contraintes de déploiement le jour de la livraison.
Une conséquence pratique importante en découle pour un projet de computer vision. Le deuxième comportement bloque davantage de projets que tous les autres, un cas ambigu resté sans arbitrage pendant deux semaines suspendant la production d’un lot entier.
Ce que ce chapitre partage avec les précédents
Trois constats reviennent depuis l’ouverture de ce parcours.
Le cadrage décide de bien plus que l’exécution technique.
Un système excellent en évaluation échoue souvent sur le terrain.
Et le seuil d’erreur acceptable relève du métier et non de la technique.
Une observation importante en découle pour un projet de computer vision. Ce chapitre ne fait que rassembler ces constats sous la forme de leurs conséquences, chaque échec décrit ici correspondant à l’un des principes que les chapitres précédents énonçaient sans encore en montrer le prix.
Ce que ce sujet a de particulier
Quatre traits distinguent cette question des autres du parcours.
Elle porte sur des décisions que personne ne juge techniques.
Elle se diagnostique après coup avec une facilité trompeuse.
Elle produit des explications qui protègent tout le monde.
Et elle se reproduit d’un projet au suivant faute d’analyse.
Une conséquence pratique importante en découle pour un projet de computer vision. Le troisième trait empêche l’apprentissage collectif, une explication commode évitant le conflit et laissant intacte la pratique qui a produit l’échec.
Ce que les premières semaines révèlent déjà
Cinq observations précoces annoncent l’issue d’un projet.
La difficulté persistante à obtenir des images réellement représentatives.
Le nombre de questions restées sans aucune réponse du métier.
L’écart constaté entre deux personnes décrivant les mêmes images.
L’absence de seuil chiffré malgré plusieurs demandes répétées.
Et la découverte tardive d’une contrainte majeure de déploiement.
Une observation importante en découle pour un projet de computer vision. Ces cinq signaux apparaissent tous avant la fin du premier mois, ce qui laisse largement le temps de recadrer un projet plutôt que de le poursuivre jusqu’à un échec annoncé.
Ce que l’arrêt d’un projet permet
Cinq bénéfices découlent d’une décision d’arrêt assumée.
Les moyens engagés se libèrent pour un projet mieux cadré.
Le corpus déjà produit reste entièrement réutilisable ailleurs.
Les enseignements se documentent pendant qu’ils restent frais.
La confiance des équipes métier se trouve ainsi préservée.
Et le besoin réel peut alors être reformulé sereinement.
Une conséquence pratique importante en découle pour un projet de computer vision. Le dernier bénéfice justifie souvent l’arrêt, un projet repris six mois plus tard sur un cadrage correct aboutissant là où la poursuite obstinée du premier n’aurait mené nulle part.
Ce que le pilote mal conçu produit
Cinq écarts rendent un pilote trompeur plutôt qu’informatif.
Un site soigneusement choisi parmi les plus favorables du parc.
Une durée bien trop courte pour observer les variations réelles.
Un accompagnement rapproché dont le déploiement ne bénéficiera pas.
Des utilisateurs volontaires ainsi que particulièrement motivés.
Et un volume traité sans aucune commune mesure avec l’usage prévu.
Une observation importante en découle pour un projet de computer vision. Le troisième écart fausse le résultat le plus discrètement, un pilote suivi quotidiennement par l’équipe technique masquant précisément les difficultés que le déploiement fera apparaître partout.
Trois questions à poser devant un projet qui patine
Trois questions orientent un diagnostic en quelques minutes.
Le seuil visé avait-il été écrit avant le démarrage.
Les erreurs portent-elles sur des cas absents du corpus.
Et les utilisateurs finaux ont-ils été consultés au cadrage.
Ces trois questions se posent sans compétence technique, elles désignent la cause dans la plupart des situations, et leur absence conduit à chercher longtemps une explication technique à un problème qui n’en est pas un.
Ce que ce chapitre suppose du prestataire
Cinq pratiques distinguent un partenaire d’un simple exécutant.
Refuser de démarrer sans un seuil d’acceptation clairement écrit.
Signaler toute contrainte de déploiement ignorée par le client.
Demander à rencontrer tous les utilisateurs finaux du dispositif.
Annoncer une limite réellement atteinte plutôt que de prolonger les itérations.
Et proposer d’arrêter un projet dont le cadrage initial condamne l’issue.
Une conséquence pratique importante en découle. La dernière pratique met fin à une facturation en cours et fonde la relation suivante, un client à qui l’on a évité de dépenser en vain revenant avec les projets où la dépense se justifie.
Ce que le succès d’un projet suppose
Cinq conditions se retrouvent dans les projets qui aboutissent.
Un commanditaire métier engagé ainsi que disponible du début à la fin.
Un seuil d’acceptation écrit et jamais déplacé ensuite.
Un corpus construit directement à partir des conditions réelles d’usage.
Des utilisateurs finaux associés bien avant la première livraison.
Et un dispositif de suivi prévu dès la phase de cadrage initial.
Une observation importante en découle pour un projet de computer vision. Ces cinq conditions relèvent toutes de l’organisation plutôt que de la technique, ce qui explique que deux équipes également compétentes obtiennent des résultats sans commune mesure.
Ce que le second projet gagne du premier
Cinq acquis subsistent même après un échec assumé.
Un référentiel écrit puis éprouvé sur des cas bien réels.
Un jeu de test constitué directement à partir du terrain.
Une connaissance précise des conditions difficiles du site.
Une équipe métier formée aux questions à trancher.
Et une estimation désormais fiable du temps de description réel.
Une conséquence pratique importante en découle pour un projet de computer vision. Ces cinq acquis ne se perdent que si personne ne les documente au moment de l’arrêt, ce qui rend cette documentation plus utile que la recherche des responsabilités.
Ce que la promesse commerciale ajoute au risque
Cinq écarts naissent entre ce qui est vendu et ce qui sera livré.
Un taux annoncé mesuré sur un jeu public sans aucun rapport.
Une démonstration conduite sur des images soigneusement choisies.
Un délai proposé sans le moindre examen des données du client.
Un périmètre décrit sans mention du contrôle qualité.
Et une maintenance évoquée sans être jamais réellement chiffrée.
Une observation importante en découle pour un projet de computer vision. Ces cinq écarts créent une attente qu’aucune exécution correcte ne pourra satisfaire, ce qui produit un échec perçu là où le résultat obtenu était en réalité conforme à ce qui était possible.
Ce que la reprise d’un projet abandonné exige
Cinq vérifications précèdent la relance d’un dispositif arrêté.
L’identification écrite de la cause réelle du premier échec.
La vérification que le corpus déjà existant reste exploitable.
L’actualisation du référentiel selon tous les enseignements tirés.
La reconstitution d’un jeu de test issu des conditions actuelles.
Et l’engagement d’un commanditaire métier réellement disponible cette fois.
Une conséquence pratique importante en découle pour un projet de computer vision. La première vérification conditionne toutes les autres, une relance conduite sans avoir nommé la cause initiale reproduisant le même échec avec des moyens supplémentaires.
Ce qu’il faut retenir
Les projets échouent au cadrage et le découvrent au déploiement.
Trois lectures se dégagent. Un seuil d’acceptation non écrit rend le projet impossible à conclure, aucun résultat ne permettant de le déclarer réussi ou abandonné. Un jeu de test mal séparé masque tous les autres défauts, une évaluation flatteuse empêchant de découvrir à temps ce que le corpus ne contenait pas. Et un système sans bénéfice pour ses utilisateurs sera contourné quelles que soient ses performances, ce qui place l’adoption au même rang que la technique.
Pour les outils disponibles, l’article sur l’open source en vision le détaille. Pour les modèles récents, l’article sur la vision multimodale l’expose.
Pour approfondir les modalités d’exécution, les formats pris en charge et les dispositifs de contrôle applicables, vous pouvez consulter notre page dédiée à l’annotation 2D et 3D. Et si vous préparez un projet de vision, échangeons sur votre besoin.