Sommaire
Réponse directe
Google Sheets seul convient encore à un très petit volume mono-agent avec discipline stricte. Dès que plusieurs personnes opèrent en parallèle ou que le volume monte, les risques opérationnels augmentent : écrasements de cellules, statuts divergents, doublons d’envoi, stock approximatif. ERP-STOK peut recevoir des lignes via Apps Script + webhook (push et/ou poll), puis centralise confirmation, livraison, stock au ramassé et retours — ce n’est pas une synchronisation native Google API. Sheets n’est pas « dangereux » par nature : c’est un outil de tableur qui atteint ses limites quand il remplace un système d’opération COD.
Trois modèles à comparer
Le modèle Sheets → ERP est fréquent au Maroc : les ads ou assistants remplissent le sheet ; ERP-STOK ingère puis opère. Le piège est de continuer à cocher « confirmé » ou « livré » dans le Sheet en parallèle de l’ERP — vous recréez deux systèmes.
| Modèle | Rôle de Sheets | Rôle de l’ERP |
|---|---|---|
| Sheets seul | Source + opération (confirmé, livré, stock) | Aucun |
| Sheets → ERP | Saisie / import ads ou assistant | Confirmation, livraison, stock, retours |
| ERP complet | Optionnel (export ou abandon) | File unique de bout en bout |
Quand Sheets reste acceptable (petit mono-agent)
Un fondateur seul, moins d’une dizaine de commandes/jour, un transporteur, peu de variantes stock : le Sheet peut tenir si une seule personne maîtrise le fichier et si les colonnes sont stables.
Ce n’est pas une question de sécurité informatique : Google Sheets peut être partagé proprement. Le risque est opérationnel — qui a la dernière version de la vérité quand le volume ou l’équipe grandit.
| Critère | Sheets seul encore OK | Signal pour basculer vers ERP ops |
|---|---|---|
| Agents simultanés | 1 personne « maître du fichier » | ≥ 2 sur confirmation ou dispatch |
| Volume indicatif | Très faible, rythme maîtrisé | Dizaines/jour, plusieurs sources (ads, Shopify, WhatsApp) |
| Statuts | Une colonne confirmé/livré suffit | Besoin d’historique, notes, relances planifiées |
| Stock | Formule ou colonne manuelle tolérable | Variantes, retours, ramassé transporteur à tracer |
| Transporteurs | Export manuel occasionnel | Envoi API + polling statuts |
| Doublons | Rare, contrôle visuel | Re-push Sheet, multi-sources, même client deux fois |
Pourquoi le volume et le multi-agent rendent Sheets risqué
Sheets n’est pas « hackable » ou « non sécurisé » par défaut. Les problèmes viennent de la concurrence humaine sur un fichier partagé et de l’absence de cycle de vie commande structuré.
Deux agents modifient la même ligne : la dernière sauvegarde gagne — l’autre ne le voit pas toujours. Un onglet « Confirmés » et un onglet « À appeler » divergent.
Le stock « confirmé mais pas parti » n’est pas déduit au bon moment dans un Sheet : soit vous déduisez trop tôt (ruptures fictives), soit trop tard (survente). ERP-STOK aligne la déduction sur le ramassage transporteur, pas sur la confirmation.
Les doublons arrivent quand la même ligne est re-poussée, qu’un client rappelle sur deux canaux, ou que deux assistants saisissent le même numéro sans ID externe.
- Plusieurs personnes cochient confirmé/livré en même temps.
- Impossible de savoir qui a parlé au client en dernier.
- Stock Sheet ≠ stock entrepôt après une semaine chargée.
- Même client envoyé deux fois au transporteur.
- Pas de lien fiable entre tracking transporteur et ligne Sheet.
- Retours physiques non tracés — stock restauré « à la main ».
Rôles et cycle de vie : ce que Sheets ne centralise pas
Une opération COD complète traverse : ingestion → confirmation call center → envoi transporteur → tracking / polling → ramassé → livraison ou refus → retour entrepôt → restauration stock. Un Sheet peut lister des lignes ; il ne garantit pas des transitions verrouillées ni un historique par agent.
| Étape | Dans Sheets seul | Dans ERP-STOK |
|---|---|---|
| Ingestion | Saisie manuelle ou formulaire | Webhook Sheets, Shopify, autres sources + external_order_id |
| Confirmation | Colonne ou onglet | File agents, statuts d’appel, relances, notes |
| Envoi livraison | Export / copier-coller | sendToDelivery, tracking, sent_to_delivery_by |
| Stock | Formule ou colonne manuelle | Déduction au ramassé (pickup), idempotence tracking |
| Retour | Note libre | return_pending_scan, scan session, validation entrepôt |
| Anti-doublon | Discipline humaine | external_order_id, contrôles à l’import |
Comment fonctionne l’intégration ERP-STOK (Sheets → ERP)
Installation d’un Apps Script dans le classeur, vérification setup(), URL webhook tokenisée, mapping des colonnes, import des lignes.
Les identifiants externes (external_order_id) aident à éviter les doublons lors d’un re-push. Les modes push (Apps Script pousse) et poll / sync manuel existent ; le job de poll rappelle que le push reste souvent plus fiable.
- Activer l’intégration Sheets du tenant et générer le script.
- Coller le script, exécuter setup(), vérifier la connexion.
- Mapper les colonnes (client, téléphone, ville, articles, ID externe…).
- Pousser les nouvelles lignes (ou lancer une sync selon mode).
- Traiter les commandes dans la file confirmation ERP-STOK — arrêter de cocher confirmé/livré dans le Sheet.
Comparatif équitable ERP-STOK vs Google Sheets (ops COD)
L’ERP n’est pas « meilleur » dans l’absolu : il est adapté quand l’opération dépasse ce qu’un tableur peut tenir sans erreur humaine récurrente.
| Sujet | Google Sheets (ops seul) | ERP-STOK (ops complète) |
|---|---|---|
| Coût / simplicité | Gratuit, familier, démarrage rapide | Abonnement ; courbe d’apprentissage agents |
| Multi-agents | Fragile sans discipline extrême | Assignation, historique, files dédiées |
| Confirmation | Colonnes libres | Statuts, rappels planifiés, notes structurées |
| Livraison + tracking | Manuel ou export | Intégrations transporteur, polling statuts |
| Stock COD | Approximatif ou formules | Déduction au ramassé, restauration après retour validé |
| Doublons multi-sources | Difficile à garantir | external_order_id à l’ingestion |
| Reporting livraison | Tableaux croisés maison | COD Delivery Insights (ville, produit livré) |
| Petit volume solo | Peut suffire encore | Peut être « lourd » — choix conscient |
Limites à connaître
Ce n’est pas une synchronisation native « Google Sheets API » côté produit marketing : le pont repose sur Apps Script + webhook.
La qualité dépend du mapping et de la discipline de saisie. Un poll mal configuré peut retarder l’import.
Migrer vers ERP-STOK sans former les agents (double file Sheet + ERP) coûte plus cher que le Sheet seul.
Exemple fictif
Exemple opérationnel
Équipe A (mono-agent, 8 cmd/jour) : un Sheet avec colonnes client, ville, confirmé. Fonctionne tant qu’une seule personne touche le fichier. Équipe B (3 agents, 45 cmd/jour) : le Sheet a « Confirmés_jour » et « Stock_manuel ». Deux agents cochent confirmé ; le stock Sheet affiche 12, l’entrepôt en a 9. Apps Script pousse vers ERP-STOK avec external_order_id ; les agents basculent sur la file ERP. Le Sheet n’est plus utilisé pour cocher livré — le tracking et le ramassé pilotent stock et statuts.
Limites et points d’attention
- Pas de synchronisation native Google API présentée comme magique : le modèle est Apps Script + webhook.
- Le polling a des limites de fraîcheur et de configuration.
- Sheets n’est pas présenté comme « dangereux » : les limites sont opérationnelles (volume, rôles, cycle de vie).
- Petit volume mono-agent : Sheet ops peut encore suffire — sans promesse ERP obligatoire.