Réponse courte : la question n’est pas « puis-je créer un champ ? » mais « où ce champ existe-t-il ensuite ? ». Un champ qui apparaît sur une fiche mais qu’on ne peut ni filtrer, ni exporter, ni utiliser dans une règle de gestion n’est pas un champ personnalisé : c’est un commentaire avec une étiquette. La différence se mesure en démonstration, en six questions.
Qu’est-ce qu’un champ personnalisé ?
Un champ personnalisé est une donnée que vous ajoutez vous-même à une entité du logiciel (un projet, un client, un collaborateur, une facture) et que le système traite ensuite exactement comme ses champs natifs : typée, filtrable, exportable, utilisable dans les règles et disponible dans l’API.
Le mot important est ensuite. Créer le champ est la partie facile, et c’est celle que toutes les démonstrations montrent.
Pourquoi un commentaire libre ne suffit pas
La solution de contournement classique consiste à ranger l’information manquante dans un champ « notes ». Elle fonctionne quelques mois, puis coûte cher :
- on ne peut pas trier ni filtrer sur du texte libre rempli par douze personnes ;
- la donnée n’existe pas dans les exports, donc elle est ressaisie à la main dans Excel ;
- aucune règle ni aucune alerte ne peut s’appuyer dessus ;
- les valeurs divergent (« confidentiel », « Confidentiel », « CONF. ») et l’analyse devient impossible ;
- personne ne sait si le champ est à jour, donc personne ne s’y fie.
Le coût n’apparaît jamais dans un budget. Il apparaît dans le temps passé à reconstruire l’information dans un tableur.
Les six questions à poser en démonstration
Faites créer un champ sous vos yeux, puis posez-les dans cet ordre :
- Sur quelles entités puis-je en ajouter ? Un outil qui n’autorise les champs que sur les projets vous bloquera le jour où le besoin portera sur les collaborateurs.
- Quels types sont disponibles ? Texte, nombre, date, liste de valeurs, oui/non. Une liste fermée vaut mieux qu’un texte libre partout où l’analyse compte.
- Puis-je le rendre obligatoire ? Un champ facultatif est un champ vide sur la moitié des fiches, et une analyse sur la moitié des fiches n’est pas une analyse.
- Apparaît-il dans le constructeur de rapports ? Demandez à l’ajouter comme colonne et comme filtre, tout de suite, pendant la démonstration.
- Sort-il dans les exports et dans l’API ? C’est ce qui décide s’il sera exploitable par votre BI et vos autres outils.
- Puis-je l’utiliser dans une règle ou une alerte ? C’est la marche la plus haute, et celle qui sépare un vrai champ d’un champ décoratif.
Si les réponses aux questions 4, 5 et 6 sont « pas encore » ou « via un développement », vous n’achetez pas un produit paramétrable.
Champ personnalisé ou tag : lequel choisir ?
Les deux servent à décrire ce que le produit standard ne décrit pas, mais ils ne répondent pas à la même question.
| Champ personnalisé | Tag | |
|---|---|---|
| Sert à | Porter une donnée propre à une fiche | Classer selon un axe partagé |
| Exemple | Numéro de marché, niveau d’habilitation | Business unit, modèle de contrat |
| Valeurs | Libres ou listées | Une liste courte et fermée |
| Usage typique | Restitution, export, règle | Regroupement et comparaison |
| Point de vigilance | Rester filtrable | Conserver l’historique des changements |
En règle générale : si vous comptez regrouper par cette information, c’est un tag, et il faut alors vérifier qu’il est historisé. Si vous comptez la lire ou la transmettre, c’est un champ.
Et si le champ demande un développement ?
Cela arrive, et un éditeur honnête vous le dit avant de vous engager. La ligne de partage est en général simple : ajouter une donnée et la faire circuler relève du paramétrage, tandis qu’un comportement nouveau du produit (un calcul, un contrôle, une intégration) relève du développement. Ce qui compte, c’est de savoir de quel côté vous êtes avant la signature, avec un délai et, s’il y a lieu, un chiffrage.
En pratique
Dans AlibeeZ, un champ ajouté depuis l’administration se retrouve dans les écrans, les rapports et tableaux de bord, l’API, les exports Excel et CSV, et les règles personnalisées. Le parcours complet, du champ manquant au champ disponible partout, est illustré sur la page personnalisation, avec la possibilité de l’essayer sur une base de test avant la production.
Questions fréquentes
Qu’est-ce qu’un champ personnalisé dans un ERP ?
C’est une donnée que vous ajoutez vous-même à une entité du logiciel (projet, client, collaborateur, facture) et que le système traite ensuite comme ses champs natifs : typée, filtrable, exportable, utilisable dans les règles et disponible dans l’API.
Quelle différence entre un champ personnalisé et un champ « notes » ?
Un champ « notes » contient du texte libre : on ne peut ni le filtrer, ni s’appuyer dessus pour une règle, et il ne sort pas proprement dans les exports. Un vrai champ personnalisé est typé et circule dans tout le produit, ce qui le rend exploitable.
Faut-il choisir un champ personnalisé ou un tag ?
Si vous comptez regrouper vos analyses selon cette information, c’est un tag, et il faut alors vérifier qu’il est historisé. Si vous comptez la lire, l’exporter ou la transmettre à un autre outil, c’est un champ personnalisé.
Ajouter un champ personnalisé demande-t-il un développement ?
En général non : ajouter une donnée et la faire circuler relève du paramétrage. Un développement devient nécessaire quand le besoin porte sur un comportement nouveau du produit : un calcul, un contrôle ou une intégration.
