CRM
Coopérative agricole : votre adhérent est à la fois fournisseur et client, votre CRM le sait-il ?
par Paul Mantez, Co-fondateur & Développeur
Quand une coopérative agricole compare des CRM, elle regarde des démonstrations faites pour des entreprises qui vendent. Un compte, des contacts, des opportunités, un devis, une facture. Tout semble aller, jusqu'au moment où quelqu'un pose la question qui fait tomber la démonstration : « et l'adhérent qui nous livre son lait, il est où là-dedans ? »
Il n'y est pas. Dans le modèle standard d'un CRM, un compte est quelqu'un à qui l'on vend. Dans une coopérative, l'adhérent apporte sa production, achète ses intrants, détient des parts et vote en assemblée. Quatre rôles pour une seule exploitation. C'est de là que viennent la plupart des difficultés, et c'est ce qu'on regarde en premier quand on intervient sur ce type de plateforme, comme chez Ingredia et sa coopérative Prospérité Fermière.
L'erreur de départ : deux fiches pour une exploitation
La tentation est mécanique. Puisque le CRM ne sait modéliser qu'un client, on crée un compte « adhérent » pour l'apport, et un compte « client » pour la vente d'intrants. Le jour de la mise en service, ça marche.
Six mois plus tard, l'exploitation a changé d'adresse d'un côté et pas de l'autre. Le fils a repris la ferme, il est contact sur une fiche et pas sur l'autre. Le technicien ne sait plus laquelle est la bonne. Et personne ne peut répondre à une question pourtant simple : combien cet adhérent nous a-t-il apporté, et combien nous a-t-il acheté, sur l'année ?
Le bon découpage tient en une phrase : un compte pour l'exploitation, des objets distincts pour chaque activité. Les contrats d'apport, les livraisons et les analyses portent la relation d'approvisionnement. Les commandes d'intrants portent la relation commerciale. Les deux pointent vers le même compte, et la vue consolidée se fait toute seule. C'est un peu plus de travail au cadrage, et beaucoup moins de correctifs ensuite.
Ce que la coopérative a en plus d'une entreprise classique
Quatre spécificités reviennent à chaque projet, et aucune n'est couverte par un CRM sorti de sa boîte.
Le contrat d'engagement. Un adhérent s'engage sur des volumes, parfois sur une durée, avec des conditions liées à la qualité de sa production. Ce contrat n'est pas un devis : il ne se transforme pas en commande, il encadre des livraisons qui s'étalent sur des mois.
La qualité comme donnée structurante. Une livraison n'est pas seulement une quantité. Elle porte des analyses, qui déterminent le prix payé. Le même volume ne vaut pas la même chose selon ses résultats. Le CRM doit savoir afficher les deux, sinon l'adhérent ne comprend pas son règlement.
Le paiement à l'envers. Dans une entreprise classique, le client paie. Ici, la coopérative paie l'adhérent pour ses apports, et l'adhérent paie la coopérative pour ses achats. Les deux flux se croisent, et se compensent parfois. Un modèle qui ne sait pas représenter une dette dans les deux sens finit dans un tableur parallèle.
La gouvernance. L'adhérent est sociétaire. Il a des parts, une voix, des convocations. Ce n'est pas du CRM commercial, mais ça vit souvent au même endroit, et il vaut mieux l'avoir prévu que l'ajouter dans l'urgence avant une assemblée générale.
Le portail adhérent est le vrai produit
Dans une coopérative, l'interface qui compte n'est pas celle des commerciaux, c'est celle de l'adhérent. C'est elle qui décide si la plateforme est utile ou si elle reste un outil de siège.
La règle qu'on applique pour décider ce qu'on y met est simple : afficher ce qui déclenche sinon un appel téléphonique. Concrètement, cela donne les apports du mois avec leurs analyses, l'état des contrats et des engagements, les factures et les paiements, et l'historique sur plusieurs campagnes. Un portail qui ne propose que des documents à télécharger ne remplace aucun appel : l'adhérent appelle quand même, parce qu'il veut comprendre un chiffre, pas récupérer un PDF.
Chez Ingredia, le portail des éleveurs sert exactement à ça, avec les apports de lait, les contrats et les factures, à côté d'une boutique en ligne d'intrants et des outils des techniciens de collecte. Les évolutions qu'on y livre passent toujours par une validation sous un profil d'éleveur, jamais sous un profil administrateur, pour une raison évidente : ce que voit l'adhérent est la seule mesure qui compte. On a détaillé cette mécanique de maintenance dans un article dédié.
Un exemple de ce que demande le terrain, et qu'aucun cahier des charges n'anticipe : un filtre pour exclure une catégorie de livraison précise dans l'affichage mensuel. Rien de spectaculaire, mais c'est ce genre de détail qui fait qu'un éleveur consulte son portail au lieu d'appeler.
La donnée de flux ne vit pas dans le CRM
Une coopérative produit énormément de données : pesées, analyses, tournées de collecte, lignes de règlement. La tentation est de tout charger dans le CRM pour tout montrer.
C'est une erreur d'architecture. Ces données viennent de l'ERP et des outils de collecte, où elles sont à leur place. Le CRM en reçoit ce qu'il doit afficher, agrégé au bon niveau : le mois, la campagne, le contrat. Le détail reste disponible, mais il n'a pas à peupler des millions d'enregistrements dans une plateforme dont ce n'est pas le métier.
Le symptôme d'un mauvais découpage se voit vite : les tableaux de bord mettent du temps à s'afficher, les jeux de données grossissent sans que personne ne les retaille, et des avertissements s'accumulent sans bloquer. Personne ne les regarde jusqu'au jour où un chiffre est faux devant un adhérent.
Qui voit quoi, et pourquoi c'est le sujet le plus sensible
Un adhérent voit ses données, et uniquement les siennes. Un technicien voit son secteur. Le siège voit tout. Cette règle paraît évidente ; sa mise en œuvre est l'endroit où les projets dérapent.
Dans un CRM avec portail, elle se traduit par une sécurité au niveau de la ligne, appliquée aux objets de contrat, de livraison et de facturation. Le point à surveiller particulièrement, ce sont les tableaux de bord analytiques : ils reposent souvent sur des jeux de données préparés à part, où la règle de visibilité doit être posée une seconde fois. C'est là que les fuites se produisent, pas dans les fiches.
Dernier point qui vaut d'être dit : les intégrations vieillissent. Une connexion entre l'ERP et le CRM installée il y a cinq ans avec un identifiant et un mot de passe finira par ne plus fonctionner, parce que les éditeurs retirent ces modes d'authentification. Mieux vaut migrer vers un mécanisme moderne pendant que tout fonctionne, en gardant l'ancien canal actif jusqu'à la bascule, que découvrir la coupure un matin de collecte.
Par où commencer
Si vous êtes une coopérative et que le sujet CRM revient sur la table, l'ordre qui fonctionne est celui-ci.
| Étape | Ce qu'on y décide |
|---|---|
| Cadrage des rôles | Un compte par exploitation, quels objets portent l'apport, l'achat, la part sociale |
| Contrats et qualité | Comment un engagement encadre des livraisons, où vivent les analyses et le prix |
| Flux depuis l'ERP | Ce qui remonte, à quel niveau d'agrégation, à quelle fréquence |
| Droits | Ce que voit l'adhérent, le technicien, le siège, y compris dans l'analytique |
| Portail | Ce qui remplace un appel téléphonique, et rien d'autre au premier lot |
Le portail arrive en dernier. C'est contre-intuitif, parce que c'est ce que tout le monde veut voir, mais un portail qui affiche une donnée fausse fait plus de dégâts qu'un portail qui n'existe pas encore.
Questions fréquentes
Un CRM classique convient-il à une coopérative agricole ?
Pas tel quel. Un CRM du marché modélise un compte qui achète. Dans une coopérative, l'adhérent apporte sa production, achète ses intrants, détient des parts et vote. Il faut donc ajouter les rôles manquants au modèle de données, plutôt que de créer deux fiches pour la même personne, sinon le portail et les statistiques deviennent faux.
Faut-il un compte séparé pour l'activité d'apport et l'activité d'achat d'un même adhérent ?
Non, un seul compte avec deux relations distinctes. Deux comptes obligent à synchroniser deux fiches pour la même exploitation, font doubler les adresses et les contacts, et cassent toute vision consolidée. Le bon découpage consiste à garder un compte unique et à porter chaque activité par ses propres objets : contrats et apports d'un côté, commandes d'intrants de l'autre.
Qu'est-ce qu'un portail adhérent doit afficher au minimum ?
Ce que l'adhérent ne peut pas obtenir autrement sans appeler quelqu'un : ses apports du mois avec leurs analyses, l'état de ses contrats et de ses engagements, ses factures et ses paiements. Le reste est du confort. Un portail qui n'affiche que des documents à télécharger ne remplace aucun appel téléphonique.
Comment gérer la saisonnalité et les volumes dans un CRM agricole ?
En séparant la donnée de flux, qui arrive en masse et régulièrement, de la donnée de relation, qui change peu. Les apports, les analyses et les pesées viennent d'outils de collecte ou de l'ERP et alimentent des objets dédiés, agrégés pour l'affichage. Charger des millions de lignes brutes dans le CRM pour les montrer telles quelles est le meilleur moyen de rendre le portail lent et les tableaux de bord fragiles.
Qui doit voir quoi dans une coopérative ?
La règle est stricte : un adhérent voit ses données et seulement les siennes, un technicien voit son secteur, le siège voit tout. Dans un CRM avec portail, cela se traduit par une sécurité au niveau de la ligne, à vérifier aussi sur les tableaux de bord analytiques, qui sont l'endroit où les fuites se produisent le plus souvent.
Combien de temps prend la mise en place pour une coopérative ?
Le cadrage du modèle de données est la phase déterminante, comptez plusieurs semaines pour trancher les rôles, les contrats et les droits. La mise en œuvre dépend ensuite du nombre de flux repris depuis l'ERP et les outils de collecte. Le portail arrive en dernier, une fois que la donnée qu'il affiche est fiable, jamais avant.
Une coopérative n'est pas une entreprise avec des clients agriculteurs. C'est une structure où la même personne apporte, achète et décide. Un CRM qui ne sait représenter que le deuxième de ces trois rôles produira des chiffres justes en apparence et faux en pratique.
Votre plateforme doit servir vos adhérents autant que votre siège ? On cadre le modèle avant d'ouvrir le portail →