L'arrivée des magasins Target au Canada fut l'un des pires fiascos économiques de l'Histoire. L'enseigne, omniprésente aux Etats-Unis, ouvrit 127 magasins au Canada en 2013. Deux ans plus tard, après plusieurs milliards de dollars de pertes, ils furent tous fermés.
Plusieurs raisons expliquent cet échec retentissant : la déception des clients d'une part, des difficultés logistiques et des erreurs grossières dans les logiciels de la compagnie (confusion entre des cm et des pouces ou entre dollar américain et canadien par exemple).
Commentaires préférés (3)
On peut dire que Target a vraiment raté sa cible !
Je suis frappé par l'insuffisance parfois criante, du support informatique de beaucoup de firmes/organismes/administrations. On a l'impression que la tâche a été confiée à n'importe qui, sans directives ni supervision. On se retrouve ainsi avec l'inaccessibilité des boutons de confirmation, des sites illisibles sur smartphone, des textes écrits en vert clair sur vert foncé... Et j'en passe
J'y étais! Au Canada, je veux dire. J'ai vu des mes yeux l'installation des magasins, avec une grosse attente des clients et la déception je l'ai aussi ressentie. Il faut connaître les magasins Target aux USA, c'est une vraie institution. Et au Canada il n'y avait pas vraiment besoin d'un autre magasin qui faisait ce que les autres faisaient, mais en moins fun. Ambience feutrée, clientèle parsemée, produits ternes et pas vraiment de produits d'appel, bref. Ça a fait flop. Le problème c'est que Target n'avait pas prévu la possibilité d'un échec commercial. Les VP n'osaient pas évoquer de plan B. Une culture d'entreprise toxique et des ingénieurs bourrés. C'est raté!
Tous les commentaires (13)
On peut dire que Target a vraiment raté sa cible !
Je suis frappé par l'insuffisance parfois criante, du support informatique de beaucoup de firmes/organismes/administrations. On a l'impression que la tâche a été confiée à n'importe qui, sans directives ni supervision. On se retrouve ainsi avec l'inaccessibilité des boutons de confirmation, des sites illisibles sur smartphone, des textes écrits en vert clair sur vert foncé... Et j'en passe
J'y étais! Au Canada, je veux dire. J'ai vu des mes yeux l'installation des magasins, avec une grosse attente des clients et la déception je l'ai aussi ressentie. Il faut connaître les magasins Target aux USA, c'est une vraie institution. Et au Canada il n'y avait pas vraiment besoin d'un autre magasin qui faisait ce que les autres faisaient, mais en moins fun. Ambience feutrée, clientèle parsemée, produits ternes et pas vraiment de produits d'appel, bref. Ça a fait flop. Le problème c'est que Target n'avait pas prévu la possibilité d'un échec commercial. Les VP n'osaient pas évoquer de plan B. Une culture d'entreprise toxique et des ingénieurs bourrés. C'est raté!
Je sais par avance que ce que je vais écrire ne va pas plaire à beaucoup de monde, mais quand on forme des développeurs en trois mois sur un langage, bin... Faut pas s'attendre à une qualité de dingue dans l'application livrée. Et les méthodes agiles n'ont guère eu de valeur ajoutée (doux euphémisme) dans le processus de développement (par rapport aux méthodes "traditionnelles") !!!...
(Vision toute personnelle consécutive à ma propre expérience dans le domaine...)
La nasa elle-même s’est déjà plantée sur des problèmes de mesures métriques et impériales et a crashé une sonde pour cette raison, alors je ne pense pas que la méthodologie agile aie grand chose à voir dans l’équation.
Je travaille dans la création et la maintenance de sites de commerce en ligne. Beaucoup de grandes enseignes ne gèrent pas elle-meme leur site et utilisent un partenairequi gere le site pour eux. La plupart du temps ce genre de problème est causé par des lacunes dans la documentation des critères de création et des processus utilisés par les entreprises. Les développeurs sont dépendants des informations fournies pour créer le site et le connecter aux autres systèmes (Payments, entrepôt, emails...). La phase de préparation prend des mois et nous soulevons énormément de questions et de problèmes, mais nous ne sommes pas devins et chaque entreprise fonctionne un peu différemment.
L'assurance qualité est aussi souvent la responsabilité des Clients. Donc s'ils ne testent pas bien où pas tout, on se retrouve avec des bugs sévères sur le site live.
D'autre part, le client gère les priorités. Même s'il y a des bugs, ce sont eux qui décident si on les répare ou pas.
Enfin en ce qui concerne l'accessibilité, très peu de compagnies s'en préoccupent sauf si elles opèrent aux USA.
Tout dépend de la société qui délivre la prestation, mais certaines ne sont bonnes qu'à encaisser des chèques, donner des cahiers des charges incomplets à des développeurs indiens sous payés qui ne se posent pas de questions et à répondre aux soucis que le processus n'était pas bien spécifié. Et après ils reprennent des chèques pour corriger des problèmes qu'ils auraient pu tenter d'éviter dès le départ s'ils avaient fait consciencieusement leur job... Et ça peut durer longtemps comme ça ^^
Bref comme partout, y'en a qui font bien leur job et d'autres qui ne pensent qu'à s'en mettre plein les fouilles (et balek des conséquences...)
Pour avoir connu cette période, je peux vous dire de memoire que cette chaîne n'offrait pas vraiment de meilleurs prix que les autres grandes surfaces, les vêtements n'était pas spécialement beau et était assez cher, le magasin était mal entretenu et manquait d'employés sur le plancher du magasin, le restaurant ne donnait pas envie. Cette chaîne n'a jamais rien fait pour s'adapter et on juste laissé le tout s'éteindre comme un feu de camp.
Tu sais des fois pour ne pas dire souvent, c’est juste lié à un sabotage, certains employés (en rogne pour bas salaire ou absence de primes) décident de tout faire foirer pour se venger.
bizarre d'avoir cette expérience et de ne pas connaître les bases...quand le produit ne correspond pas au besoin, ce ne sont pas les développeurs qu'ils faut incriminer puisque ce ne sont pas eux qui définissent le besoin. Ce peut être le marketing, le chef de produit, si le besoin est mal défini, la validation si le produit est bon conforme, ou le chef de projet s'il a permis le développement avec un besoin imprécis ou non défini, ou laisser le produit dans validation. En scrum et méthode agile, ce rôle est d'ailleurs très bien defini, c'est le product owner qui définit le besoin fonctionnel.
signé : un chef de projet en galère car il a laissé le projet commencer sans besoin fonctionnel bien défini :)
c'est une erreur grossière de croire que ces fournisseurs veulent s'en mettre plein les poches. souvent c'est leur client qui leur impose le délai et l'impossibilité de se poser des questions, parfois à juste raison car trop tard ou trop coûteux fait perdre les marchés. Les reprises sont plus coûteuses donc c'est normal de faire payer pour. Par ailleurs, croire que tout peut être intégralement défini correctement en début de projet est aussi une erreur. il faut souvent des maquettes, des protos, des préserves pour avoir un produit de qualité, ça ne se fait jamais en une fois. Toutes les méthodologies de projet incluent des boucles, même les cycles en V qui sont censées être rigoureuses voire rugueuses, et même hors développement entre l'amélioration continue et le product life. penses aux produits de grande série, comme les smartphone ou les applications grand public, les reprises sont constantes.
Tout à fait. Les entreprises qui gèrent les sites n'ont pas intérêt à livrer un produit défectueux. C'est un milieu assez fermé et les réputations se défont très vîte. Un bon projet est la meilleure publicité pour attirer de nouveaux clients. Et ainsi que tu le dis, même les très bons projets sont lancés avec des bugs qui sont censés être résolus post-live.
Comme je l'ai mentionné, ce sont les clients qui décident des priorités et souvent ils sont plus intéressés par le développement de nouvelles fonctionnalités que la résolution de bugs qui n'affectent qu'un petit nombre de clients.
Une partie de mon rôle consiste justement à les encourager à mettre plus d'efforts dans la résolution de ces bugs car plus l'application évolue plus il y a de risque que le problème devienne plus gênant.
tu l'as mieux exprimé que moi. j'ajoute quand même que, ce que beaucoup de développeurs ("le cul devant un bureau" pour caricaturer, je l'ai moi même été) oublient, ce que ces reprises ne sont pas uniquement pour les phases de développements mais aussi pour celles de définition de besoin, que ce soit en mécanique ou en numérique d'ailleurs. L'exemple typique est celui d'un retour de salon, ou de démonstration, de concept. A ce stade le produit doit être suffisament abouti pour convaincre le marché, ça veut dire que le développement est lancé. Parfois le cahier des charges fonctionnel est retouché suite à ces événements car ce sont les premiers retours clients sur un vrai produit. Le besoin est alors redéfini et il faut défaire ce qui a été fait... Et les raisons sont simples, tous les marchés ne "justifient pas" d'étude marketing longues et coûteuses, les clients peuvent se tromper sur leurs besoins (assez fréquent je pense dans l'ergonomie d'un site Web par exemple)... la reprise peut être justifiée par le client ou en interne, suivant le definisseur du besoin, ça ne change rien au fait qu'il est impossible de définir précisément un besoin dans beaucoup de cas, car ce n'est pas une science exacte, et ceux même pour des produits simples. Un exemple simple avec un pneu,qui est un compromis coût / longévité / vitesse (pour simplifier). combien de clients préfèrent payer combien d'argent pour quelle vitesse et longévité supolementaires ? impossible de répondre scientifiquement puisque les gens eux memes ne se posent pas la question et parce que chacun aura une réponse différente.