#Construire un site pour une cliente, et le lui remettre

Ce guide suit une cliente du premier appel au site en ligne, du point de vue d'un partenaire Webcosa. Il n'invente rien : chaque étape existe, avec son écran ou sa commande, et ce qui se passe en base est dit.

#Ce qu'est un partenaire

Un compte ordinaire, inscrit par l'agence dans une liste de partenaires. Il ne voit que ses sites ; il en crée sans plafond ni essai — ils naissent en atelier : à lui, toutes capacités ouvertes, rien de facturé — et il peut les transférer à une cliente. L'agence a les mêmes gestes, sur tous les sites.

Deux entrées, une seule identité :

• partner.webcosa.com — l'espace partenaire. L'accueil montre ce qui a été encaissé sur la période (les mises en route réglées sur les devis), un résumé du portefeuille — ce qui attend un geste : lien de reprise expiré ou pas ouvert, devis pas ouvert ou signé sans être réglé, fin d'essai proche, domaine pas vérifié, site réglé pas encore remis — et le journal des changements de cette documentation. Sites : une seule liste, chaque site avec son type (Développement, En cours de transfert, Collaboration), son statut, sa cliente, son forfait (payé, ou prévu tant qu'il est en atelier) ; un clic ouvre sa fiche — alertes, visites mesurées, transfert, cliente et devis, adresses, versions du thème, activité. Puis les clientes (celles que nomment un devis, un lien de reprise ou un site créé pour elles), les devis (création, envoi, suivi) et les clés d'API (la portée atelier s'y crée, réservée aux partenaires : 403 portee_reservee ailleurs). Réservé aux partenaires ; un client Webcosa qui s'y connecte voit qu'il n'a rien à y faire.
• cms.webcosa.com — le CMS, où chaque site s'ouvre d'un clic depuis la liste (/ouvrir/<site>, ou /ouvrir/<site>?vers=/parametres pour arriver sur un écran précis). Même session : le cookie vit sur .webcosa.com.

Ce que l'espace montre d'un site remis suit les droits de l'éditeur : son abonnement et son journal d'activité appartiennent à la cliente, ils n'y apparaissent pas.

Et le CLI, avec une clé de portée atelier : tout le parcours depuis un poste, sans navigateur — voir L'atelier.

#1. Le devis

Le site d'abord (Sites → Créer un site : le nom, le pays, le métier s'il est connu, la formule prévue — c'est tout, le thème de départ est choisi d'après le métier). Puis le devis (Devis → Créer un devis), en cinq parties : le site auquel il se rattache, la cliente (le SIRET remplit l'entreprise et l'adresse, l'adresse se complète en tapant), la prestation (formule et option Présence, le prix suit), ce qui est compris ou non, délais et montant — avec l'aperçu de ce que lira la cliente. « Créer » fait un brouillon lisible en PDF depuis sa fiche ; « Créer et envoyer » le fait partir dans la foulée. Chaque ligne a son menu — fiche, PDF, envoyer, renvoyer, corriger tant qu'il est en brouillon, annuler. Ou, depuis l'atelier, dans un fichier JSON aux mêmes champs (le site du dossier courant s'y rattache tout seul), émis en une commande :

La plateforme rend le PDF, le dépose dans un stockage privé, et envoie à la cliente « Votre devis est prêt » avec un lien signature.webcosa.com/⟨jeton⟩. Elle n'a pas de compte : le jeton (256 bits, dont la base ne garde que l'empreinte) est l'autorisation.

Sur cette page, elle lit le devis, le télécharge, puis le signe : son nom, deux cases (accord ; démarrage immédiat malgré les 14 jours de rétractation de l'art. L.221-3), et un code à six chiffres envoyé à l'adresse du devis. La signature est une signature électronique simple au sens d'eIDAS : empreinte SHA-256 du PDF original, horodatage RFC 3161 (FreeTSA, si le tiers répond), PDF signé auto-portant avec les preuves en pièces jointes, ligne devis_signatures en insertion seule.

Elle règle ensuite la mise en route (Stripe Checkout, paiement unique, facture Stripe). Le partenaire est prévenu par courriel à la signature et au paiement. On ne construit pas avant.

#Ce que voit la cliente

La page signature.webcosa.com/⟨jeton⟩ est un document à lire — ce qui est compris, ce qui ne l'est pas, les délais, l'émetteur — avec, à côté, le récapitulatif des montants et l'étape en cours, en quatre temps : 1 Lecture · 2 Signature · 3 Paiement · 4 Accès. Après le paiement de la mise en route, elle choisit un mot de passe : son compte Webcosa existe (POST /api/signature/⟨jeton⟩/compte, à l'adresse qu'elle a prouvée en signant), sa session s'ouvre, et /bienvenue lui dit « votre site est en préparation » — le devis, les dates, les éléments attendus — au lieu de lui faire créer un site. Le courriel « Paiement reçu » ramène à cette étape. Quand le site lui sera remis, il apparaîtra dans ce même espace.

#Le suivi

Dès l'envoi, la fiche du devis raconte ce que fait la cliente, dans l'ordre : envoyé, ouvert (la page de signature affichée par un vrai navigateur — pas par l'antivirus d'une messagerie qui suit les liens —, avec le nombre d'ouvertures), code demandé, signé, réglé ; ou refusé, avec le mot qu'elle a laissé ; ou expiré, ou annulé. Le partenaire reçoit un courriel à la première ouverture, à la signature, au refus et au paiement. Même journal en ligne de commande : webcosa devis etat --numero=WC-….

La cliente, elle, a sur la page un lien discret « Ce devis ne vous convient pas ? Le refuser », avec un champ pour dire pourquoi. Un devis refusé ne se signe plus ; on en propose un autre.

#2. Le site

— ou « Créer un site » dans l'espace partenaire : le nom, le pays, le métier (facultatif), la formule prévue avec l'option Présence. La cliente, elle, se nomme au devis qui se rattache au site : le transfert sera prérempli depuis ce devis, et la liste dira pour qui est chaque site (en CLI, --cliente=… --formule=… --presence --devis=WC-… posent la même intention à la main). En base : une ligne sites (status = draft, owner_id = le partenaire), une ligne abonnements (formule = atelier, etat = actif, origine = partenaire), le thème du catalogue copié dans theme_fichiers et publié, une page d'accueil, l'en-tête, le pied, le menu.

Puis le thème (theme recuperer / pousser), les pages (page ecrire), le menu, la fiche de l'entreprise, les photos — voir L'atelier.

#3. Montrer

draft → live : le site répond à ⟨slug⟩.webcosa.site. Pour que seule la cliente le voie, un code d'accès (Réglages → Accès dans le CMS) : la page « Porte » le demande, le reste du monde ne voit rien.

#4. Remettre

— ou « Transférer à la cliente » dans le menu de la ligne. Une ligne site_transferts (adresse, formule prévue, option Présence, jeton de 256 bits, quatorze jours) et un courriel « Votre site est prêt — reprenez-en la propriété » avec un bouton vers cms.webcosa.com/reprendre/⟨jeton⟩.

Si la cliente a déjà créé son accès au devis, elle se connecte avec son mot de passe (« Se connecter ») ; sinon la page lui envoie un code à six chiffres à l'adresse du transfert (et rien qu'à elle — l'adresse n'est jamais saisie) et le compte est créé au passage. Arrivée avec un autre compte, « Changer de compte » ferme la session (/auth/deconnexion) et la ramène sur le lien. Puis « Reprendre la propriété » appelle une fonction SQL qui fait tout en une transaction :

1. sites.owner_id ← la cliente, status ← suspended, actif_jusqu_au ← maintenant : le site s'endort (page « Site indisponible ») ;
2. site_membres : la cliente propriétaire, le partenaire éditeur ;
3. abonnements : formule ← celle prévue, etat ← a_activer ;
4. une ligne de journal, site.transfere.

Elle atterrit sur le choix de formule, la formule prévue présélectionnée, la Présence cochée si prévue. Le premier paiement allume le site : le webhook Stripe passe suspended → live. Aucun autre chemin ne le fait.

Le partenaire est prévenu par courriel quand la cliente demande son code (la fiche du site le dit aussi, et l'accueil signale un lien pas ouvert au bout de trois jours ou qui expire dans les trois jours), quand elle reprend le site, et quand le site passe en ligne. Un lien expiré sans reprise reste « En cours de transfert » : il se renvoie de là, avec un nouveau délai de quatorze jours.

Le partenaire reste éditeur : sa clé pousse encore le thème et écrit les pages (les corrections comprises au devis), mais la facturation et l'équipe lui sont fermées. La cliente peut le retirer depuis son écran Équipe ; il peut aussi « supprimer son accès » depuis le menu du site, dans la vue Collaborations.

#Ce qui ne peut pas arriver

• Une adresse qui a un site en attente de reprise ne peut pas s'en créer un second par l'inscription ou /bienvenue : elle est renvoyée vers son lien.
• Un lien de transfert ou de devis ne sert qu'une fois, pour une adresse, et meurt à l'expiration, à l'annulation, ou au renvoi (qui en fabrique un neuf).
• Un site repris et pas encore payé ne se met pas en ligne — ni par le CMS, ni par le CLI (402 site_a_activer).
• Un partenaire ne transfère qu'un site en atelier qui lui appartient ; jamais celui d'un client à un autre.
• Un site ne se supprime depuis l'espace partenaire que s'il est en atelier et sans transfert en cours.

#Les codes d'erreur

Voir Atelier, transfert et devis — transfert_en_attente, site_hors_atelier, transfert_deja_envoye, site_a_activer, devis_fige, devis_non_signe, code_faux…