Algeria AgencyNos offres
La file des décisions : ce que le projet attend de vous, et ce que chaque attente coûte en semaines
Un projet de ce niveau n’attend presque jamais du code. Il attend une décision, une donnée ou une photo que personne n’a encore prise.
L’article qui accompagne celui-ci explique la forme de cette offre : pourquoi construire et faire de la publicité en même temps, ce qu’un mois de développement coûte en mois de campagne, et ce que vous devez posséder à la fin.
Il décrit le projet. Celui-ci décrit l’autre moitié, celle dont personne ne parle avant de signer : ce que le projet attend de vous. Parce qu’un chantier de ce type ne s’arrête presque jamais faute de développement — il s’arrête faute d’une réponse.
La liste est courte et elle est toujours la même : le catalogue, les prix et qui peut les changer, les zones de livraison, la politique de retour, la vérité du stock, le dossier bancaire, les textes et les photos, et la personne qui valide. Aucune de ces lignes n’est technique et aucune ne figure sur un cahier des charges.
Cet article donne cette file dans l’ordre, dit ce que chaque attente coûte, et explique pourquoi nous ne vous donnerons pas de durée de projet.
Un projet n’attend presque jamais du code
Quand un chantier de ce type prend trois mois de plus que prévu, la reconstitution honnête donne presque toujours le même partage : quelques jours de travail supplémentaire, et des semaines pendant lesquelles rien n’avançait parce qu’une question était en attente.
Ces semaines-là ne ressemblent pas à de l’attente pendant qu’on les vit. Elles ressemblent à une période où le prestataire travaille sur autre chose et où vous avez beaucoup à faire par ailleurs. Personne ne les note, et à la fin chacun se souvient d’un projet lent sans savoir dire où le temps est passé.
La raison est structurelle. Le travail de développement est visible, planifié, facturé et suivi ; l’attente d’une décision n’est écrite nulle part. Une réponse qui met dix jours à venir n’apparaît sur aucun document, et pourtant elle coûte exactement dix jours au calendrier.
Il y a une conséquence agréable à cela, et c’est la raison d’être de cet article : la partie qui fait déraper les projets est la partie la moins chère à traiter. Elle ne demande ni budget ni compétence technique, seulement de savoir à l’avance ce qui sera demandé.
La méthode tient en une phrase : établissez la file des décisions au début, avec un responsable et une date pour chacune, et traitez-la comme un lot de travail au même titre que le développement. Une décision inscrite dans un plan est prise ; une décision attendue est reportée.
La file des décisions : ce qu’elle contient
Elle est plus courte qu’on ne le craint et plus précise qu’on ne l’imagine. Sur un projet de commerce en ligne avec paiement par carte, elle tient en huit lignes, et ces huit lignes reviennent d’un projet à l’autre presque sans variation.
Le catalogue et sa structure. Les prix et le droit de les modifier. Les zones de livraison et leurs tarifs. La politique de retour. La règle d’affichage du stock. Le dossier bancaire. Les textes et les photographies. Le nom de la personne qui valide.
Chacune a trois propriétés qu’il faut écrire à côté d’elle : qui peut la trancher, ce qui est bloqué tant qu’elle ne l’est pas, et la date à laquelle elle est attendue. La deuxième colonne est celle qui change les comportements — une décision devient urgente quand on voit ce qu’elle immobilise.
L’ordre compte moins qu’on ne croit, à deux exceptions près. Le dossier bancaire se commence en premier parce qu’il ne dépend pas de nous, et le catalogue se traite tôt parce que presque tout le reste s’y accroche.
Cette liste n’est pas un document contractuel et n’a pas besoin de l’être. Elle est une page, elle est relue à chaque point d’avancement, et elle est le seul endroit du projet où l’on voit la partie que le prestataire ne peut pas faire avancer.
Le catalogue est une donnée qui vous appartient, pas un livrable
L’article voisin dit que le catalogue est le vrai projet. C’est exact et cela se traduit en une chose très concrète : le catalogue est une donnée que vous détenez, pas quelque chose qu’un prestataire produit pour vous.
Ce qui est demandé n’est pas une belle mise en forme. C’est une liste où chaque produit a une référence stable, un nom qui ne change pas d’une ligne à l’autre, une catégorie, un prix, et — le point le plus souvent manquant — une décision sur ce qui distingue deux variantes du même article.
La question des variantes est celle qui coûte le plus cher quand elle est tranchée tard. Une taille et une couleur sont-elles deux produits ou un produit avec deux options ? Les deux réponses sont défendables, elles produisent des sites différents, et changer d’avis après la reprise du catalogue signifie ressaisir le catalogue.
Le second point est la stabilité des références. Un tableur où le même article est écrit de trois façons dans trois onglets ne se reprend pas automatiquement : il se relit à la main, et c’est un travail que personne n’a prévu parce qu’il ne ressemble ni à du développement ni à de la saisie.
La bonne nouvelle est que ce travail sert bien au-delà du site. Un catalogue propre est ce qui rend possibles les fiches produits, les campagnes, les places de marché et la comptabilité analytique. C’est la seule ligne de cette file qui a de la valeur même si le projet s’arrête.
Les prix, et qui a le droit de les changer
Un prix affiché en ligne n’est pas la même chose qu’un prix annoncé au comptoir, et la différence n’est pas juridique, elle est organisationnelle : en ligne, le prix est écrit, daté, visible par tous vos clients en même temps, et il ne se négocie pas au moment de l’achat.
La première décision est donc celle-ci : le prix en ligne est-il le même qu’en magasin. Les deux réponses fonctionnent, elles doivent être choisies plutôt que subies, et la seconde demande une explication écrite quelque part sur le site, sinon elle produit une réclamation par semaine.
La deuxième est le droit de modification. Qui peut changer un prix, dans quel outil, et avec quel délai de propagation. Une entreprise où trois personnes peuvent modifier un prix sans se prévenir produit des écarts entre le site, la caisse et les places de marché, et ces écarts sont visibles par les clients avant de l’être par vous.
La troisième concerne les promotions : sont-elles des prix modifiés ou des remises appliquées au panier. La distinction paraît technique et ne l’est pas — elle décide de ce que voient vos clients dans leur historique, de ce qui apparaît sur la facture, et de ce que vous pourrez analyser ensuite.
Aucune de ces trois décisions ne demande un développeur, et les trois bloquent du développement. C’est le motif qui revient dans toute cette file : ce qui est le moins technique est ce qui immobilise le plus.
Les zones de livraison, et ce qu’elles coûtent réellement
La livraison est la ligne où les projets algériens se compliquent le plus, et rarement pour des raisons techniques. Un site doit annoncer, avant le paiement, à quelles adresses il livre, en combien de temps et à quel prix. Ces trois réponses supposent des décisions commerciales que beaucoup d’entreprises n’avaient jamais eu besoin de formaliser.
La première est la maille : livrez-vous par wilaya, par commune, ou par accord au cas par cas. Le cas par cas fonctionne très bien au téléphone et ne fonctionne pas du tout sur un site, parce qu’un client qui ne peut pas connaître son coût de livraison avant de payer abandonne à cet endroit précis.
La deuxième est ce qui se passe hors zone. Refuser proprement est une décision acceptable et se code en une heure. Ne rien prévoir produit la pire des situations : une commande acceptée qui ne peut pas être honorée, découverte après l’encaissement.
La troisième est le paiement à la livraison. Beaucoup de projets veulent le paiement par carte et gardent le paiement à la livraison, ce qui est raisonnable dans ce marché — mais les deux ne se règlent pas de la même façon en cas de retour ou d’absence du client, et cette règle-là est une décision de gestion, pas une option à cocher.
Enfin, un coût de livraison qui n’est pas le vrai coût se paie tous les jours. Une expédition affichée en dessous de son prix réel devient une perte proportionnelle au succès du site, ce qui est la façon la plus désagréable de découvrir qu’une campagne a bien fonctionné.
La politique de retour est une politique, pas une page
Presque tous les projets traitent le retour comme un texte à rédiger en fin de chantier. C’est une décision de gestion, elle a des conséquences sur l’entrepôt, la caisse et la comptabilité, et elle doit être prise avant que le site ne l’annonce.
Les questions sont concrètes et se répondent en une réunion : sous quel délai, dans quel état, avec ou sans emballage d’origine, qui paie le retour, et sous quelle forme le client est remboursé — même moyen de paiement, avoir, ou échange.
La dernière est la plus lourde et personne ne l’anticipe. Rembourser une carte bancaire n’est pas la même opération que rendre des espèces : cela passe par le système de paiement, cela laisse une trace, cela a un délai, et cela demande que quelqu’un chez vous ait le droit de déclencher l’opération.
Il faut aussi décider qui reçoit le retour physiquement. Un colis qui revient sans que personne ne sache à quelle commande il correspond devient un objet dans un coin, et le client qui attend son remboursement finit par écrire publiquement — c’est la mécanique par laquelle une politique de retour absente devient un problème de réputation.
Écrite avant, cette politique tient en dix lignes et se code en une journée. Écrite après, elle demande de reprendre le tunnel de commande, la facturation et parfois la comptabilité, pour un résultat identique.
Le stock : quelle vérité le site affiche-t-il
La question paraît technique et elle est entièrement organisationnelle : quand un client voit « disponible » sur votre site, à quoi cette information correspond-elle exactement.
Il y a trois réponses honnêtes et elles se choisissent. Le site n’affiche rien et vous confirmez à la commande — simple, robuste, et pénalisant sur les gros paniers. Le site affiche un stock saisi à la main et remis à jour à une fréquence dite — praticable et fragile en période de forte activité. Le site reflète un stock tenu dans un outil de gestion — le plus juste et le plus exigeant, parce qu’il suppose que ce stock soit tenu correctement, ce qui n’est pas donné.
Le choix ne dépend pas de votre budget mais de la discipline réelle de votre réserve. Un site qui affiche un stock faux est pire qu’un site qui n’affiche rien : il produit des commandes que vous devez annuler, et une annulation coûte plus qu’une vente non faite.
C’est aussi une décision qui doit prévoir son propre échec. Que se passe-t-il si deux clients achètent le dernier article dans la même minute ? La réponse ne peut pas être « cela n’arrivera pas » : elle est soit un blocage à la commande, soit une annulation avec remboursement immédiat, et il faut avoir choisi laquelle.
Enfin, cette décision se révise. Beaucoup d’entreprises commencent sans affichage de stock, tiennent trois mois, découvrent ce que leur réserve supporte réellement, puis passent à l’affichage. C’est un ordre sain et il vaut mieux que l’inverse, qui consiste à promettre une précision qu’on ne tient pas.
Le dossier bancaire commence avant le code
L’article voisin le dit en une phrase : le dossier bancaire est un délai, pas une fonctionnalité. C’est la ligne de cette file qui ne dépend ni de vous ni de nous, et c’est exactement pour cela qu’elle se commence en premier.
Ce qui est demandé est administratif et se réunit sans nous : les pièces de l’entreprise, les informations du compte, et une description de l’activité. Rien là-dedans n’attend le site, et pourtant beaucoup de projets ne commencent ce dossier qu’une fois le site prêt, parce qu’il paraît logique d’avoir la boutique avant de demander le moyen de paiement.
Cette logique est fausse dans ce sens et vraie dans l’autre. Un site prêt qui attend son moyen de paiement est un site qui existe et ne vend pas ; un dossier prêt qui attend son site est un dossier qui ne coûte rien à personne.
Il faut aussi savoir ce qui vous sera demandé sur le site lui-même, parce que ces exigences sont connues à l’avance et se traitent pendant la construction plutôt qu’après : les conditions de vente, les mentions de l’entreprise, la politique de retour dont il vient d’être question, et des informations de contact réelles.
La conséquence pratique est une règle d’ordre, et c’est la seule de cet article qui porte sur le calendrier : commencez le dossier la semaine où le projet est signé, pas la semaine où le site est fini.
Les textes et les photos que personne n’a encore faits
C’est la ligne la plus sous-estimée de toute la file, et c’est presque toujours celle qui retarde la mise en ligne. Un site de commerce a besoin d’une photo et de quelques lignes par produit, et ces deux choses n’existent pas encore.
Le volume surprend. Cent références, c’est cent photographies et cent descriptions ; ce n’est pas un après-midi, et cela ne peut pas être fait en une fois la veille du lancement. Personne ne l’estime au début parce que, dans une réunion, « on a les photos » veut dire qu’il existe des images quelque part.
La qualité compte moins que la constance, et c’est une bonne nouvelle. Des photos prises au téléphone, sur le même fond, à la même distance, avec la même lumière, produisent un catalogue qui a l’air d’un catalogue. Des photos superbes prises dans dix conditions différentes produisent un site qui a l’air d’un assemblage.
Pour les textes, la règle utile est de commencer par les vingt produits qui font l’essentiel de vos ventes et d’accepter une description courte pour le reste. Un site qui attend cent descriptions parfaites ne se lance pas ; un site lancé avec vingt bonnes fiches et quatre-vingts lignes correctes se complète en travaillant.
La décision à prendre est simplement celle-ci : qui fait ce travail, quand, et sur quelle liste. Confié à personne, il est fait par le dirigeant, le soir, en retard, et c’est le scénario que cette section existe pour éviter.
La personne qui valide, et le gel avant la mise en ligne
Un projet a besoin d’une personne nommée qui peut dire oui. Pas d’un comité, pas d’un accord général : quelqu’un dont l’avis clôt une question, et dont l’absence est planifiée à l’avance.
Cette personne n’a pas besoin d’être le dirigeant, et c’est souvent mieux si elle ne l’est pas — un dirigeant validant chaque écran devient le goulot du projet. Elle a besoin d’un mandat clair sur ce qu’elle peut trancher seule et sur ce qui remonte, et ce partage s’écrit en trois lignes au début.
Elle a aussi besoin d’un rythme. Une validation par lots, à jour fixe, coûte moins de temps qu’un flux permanent de questions et produit de meilleures décisions, parce qu’on voit les écrans ensemble plutôt qu’un par un.
Vient ensuite le gel, qui est la mesure la plus efficace et la moins pratiquée. À une date convenue avant la mise en ligne, on arrête d’ajouter des demandes ; tout ce qui arrive après est noté pour la suite. Sans gel, un projet ne se termine pas — il ralentit indéfiniment, parce que chaque semaine apporte une bonne idée et qu’aucune bonne idée n’est refusable individuellement.
C’est la version organisationnelle du « pendant qu’on y est » dont parle l’article voisin. Là-bas c’est un piège de périmètre ; ici c’est une date à écrire, et elle est la différence entre un site en ligne et un site presque prêt depuis quatre mois.
Pourquoi nous ne donnons pas de durée de projet
La question posée en premier rendez-vous est toujours la même : combien de temps. Nous donnons des durées de tâches et nous ne donnons pas de durée de projet, et la raison n’est pas une prudence commerciale.
La durée réelle d’un chantier de ce type est la somme de deux choses : le temps de travail et le temps d’attente. Le premier est mesuré, planifié, facturé et connu — nos estimations dessus sont bonnes, parce que c’est la seule partie que nous faisons et la seule dont il existe une trace.
Le second n’est mesuré nulle part. Aucun outil de suivi n’enregistre les onze jours pendant lesquels une politique de retour n’était pas décidée, et aucun client ne les note non plus. Ce qui veut dire que la variabilité d’un projet à l’autre vient presque entièrement de la moitié dont il n’existe aucun relevé.
Une durée moyenne calculée sur des projets passés mesure donc la partie qui varie le moins et attribue au prestataire une dispersion qu’il ne produit pas. Elle est même trompeuse dans une direction précise : elle laisse croire que la date dépend de nous, ce qui est exactement la croyance qui fait que la file des décisions n’est pas traitée comme du travail.
Ce que nous mettons à la place est vérifiable et vous appartient : la file de la section 2, avec un responsable et une date par ligne, relue à chaque point. Comptez, sur votre propre projet, les jours écoulés entre la question posée et la réponse donnée. C’est le seul relevé qui ait jamais existé pour cette moitié-là, et il se tient sur une page.
Ce que nous faisons, et ce que nous refusons de faire ici
Nous établissons la file des décisions au premier rendez-vous, avec pour chaque ligne qui tranche, ce qui est bloqué, et à quelle date c’est attendu. Nous la relisons à chaque point d’avancement, avant de parler de ce qui a été développé.
Nous faisons le travail de catalogue avec vous plutôt qu’à votre place : nous fournissons le format, nous reprenons ce qui est reprenable automatiquement, et nous vous rendons la liste des ambiguïtés à trancher — parce qu’une variante décidée par nous est une décision commerciale prise par quelqu’un qui ne vend pas vos produits.
Nous refusons de donner une durée de projet. Nous donnons des durées de tâches, la file, et la date de gel ; assembler ces trois choses en un calendrier suppose de connaître vos délais de réponse, que vous seuls pouvez estimer.
Nous refusons de démarrer le développement d’un tunnel de commande tant que les zones de livraison, la politique de retour et la règle de stock ne sont pas écrites. Ce n’est pas une exigence administrative : ces trois décisions changent la structure de ce qui est construit, et les prendre après coûte une reprise que vous payez.
Et nous refusons de rédiger vos conditions de vente et votre politique de retour à votre place. Nous vous donnons la liste des points à trancher et nous les mettons en forme une fois tranchés — mais ce sont des engagements que votre entreprise prend envers ses clients, et un prestataire qui les invente vous fait signer les siens.
Questions fréquentes
Combien de temps prend un projet de ce type ?
Nous donnons des durées de tâches et pas de durée de projet. Le délai réel est du temps de travail plus du temps d’attente, et seul le premier est mesuré quelque part : la variabilité vient presque entièrement de la moitié dont il n’existe aucun relevé. La file des décisions, avec un responsable et une date par ligne, est ce qui rend le calendrier prévisible.
Par quoi faut-il commencer, concrètement ?
Par le dossier bancaire, la semaine de la signature, parce qu’il ne dépend ni de vous ni de nous. Puis par le catalogue, parce que presque tout le reste s’y accroche — et dans le catalogue, par la décision sur les variantes, qui est celle qui coûte le plus cher quand elle est tranchée tard.
Pouvez-vous écrire nos conditions de vente et notre politique de retour ?
Nous vous donnons la liste des points à trancher et nous les mettons en forme une fois tranchés. Nous ne les inventons pas : ce sont des engagements que votre entreprise prend envers ses clients, et une politique de retour écrite par un prestataire est la politique de ce prestataire.
Faut-il afficher le stock sur le site ?
Cela dépend de la discipline réelle de votre réserve, pas de votre budget. Un stock faux affiché est pire que pas de stock du tout, parce qu’il produit des commandes à annuler et qu’une annulation coûte plus qu’une vente non faite. Commencer sans affichage, puis l’activer après trois mois, est un ordre sain.
Qui doit valider chez nous ?
Une personne nommée, avec un mandat écrit sur ce qu’elle tranche seule, et validant par lots à jour fixe. Souvent pas le dirigeant : un dirigeant qui valide chaque écran devient le goulot du projet. Et prévoyez son absence à l’avance plutôt qu’au moment où elle se produit.
Pourquoi geler les demandes avant la mise en ligne ?
Parce que sans date de gel un projet ne se termine pas : chaque semaine apporte une bonne idée, et aucune bonne idée n’est refusable individuellement. Ce qui arrive après le gel est noté pour la suite. C’est la version organisationnelle du piège du « pendant qu’on y est ».
Où nous intervenons
Un projet ne prend pas le temps du développement : il prend le temps de la décision la plus lente, et celle-là n’est pas de notre côté.
- Nous mettons une date et un nom sur chaque décision dès la première séance.
- Nous préparons le gabarit du catalogue ; les fiches restent votre travail.
- Nous arrêtons les changements de périmètre à une date annoncée dès la signature.
Ne commencez pas ce niveau si rien ne peut être tranché entre deux réunions : le chantier s’arrêtera à la troisième ligne, et vous l’aurez payé.
À lire ensuite
Le mois où louer devient plus cher que construire
À partir d’un certain volume, acheter de l’attention chaque mois coûte plus cher que fabriquer ce qui la reçoit. Comment repérer ce moment, et ce qui casse si on construit trop tôt.Intégrer le paiement en ligne CIB et Edahabia
Les cartes ne sont plus le frein : elles sont 21,9 millions. Ce qui manque, ce sont les commerçants qui les acceptent.E-commerce : ce qu’on vous montre est la vitrine, ce que vous achetez est le back-office
Toutes les démonstrations montrent la boutique. Tous les coûts et tous les risques sont derrière, dans ce que personne ne dessine.
Parlons de votre projet
Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.