Chaque organisation pense que ses règles sont uniques. Une saisie à la demi-journée ici, une TVA belge là, une numérotation de factures par entité juridique, un second valideur au-delà d’un certain montant. Dans beaucoup d’outils, chacune de ces particularités devient un ticket de développement, ou pire, un contournement tenu dans un tableur à côté.

AlibeeZ part du constat inverse : la plupart de ces spécificités sont déjà connues, parce qu’on les retrouve d’une société de conseil à l’autre. Elles sont donc livrées dans le produit, sous forme de règles de gestion : plus de 400 comportements que vous activez et réglez par paramétrage. Le panneau ci-dessus en montre un échantillon de seize, répartis en trois domaines.

Ce qu’est une règle de gestion dans AlibeeZ

Une règle de gestion est un comportement paramétrable du produit : la façon dont un temps est saisi, le moment où une facture peut être émise, le seuil au-delà duquel une dépense demande un second valideur. Ces règles ne sont pas des options à développer pour vous : elles sont livrées et testées. Votre travail consiste à choisir et à régler, pas à spécifier.

Concrètement, une règle prend presque toujours l’une de ces formes :

  • Un choix parmi quelques valeurs : journée, demi-journée ou heure ; régie, forfait, jalon ou avancement.
  • Un même réglage résolu différemment selon le pays, l’entité ou le compteur : un taux de TVA par pays, un calendrier de jours fériés par implantation.
  • Une quantité face à un seuil : une enveloppe consommée à 82 % quand l’alerte est fixée à 80 %.
  • Une condition et ce qu’elle déclenche : au-delà de tel montant, tel valideur.
  • Un format : la structure d’un numéro de facture, entité, exercice, séquence.

Ce que montre le panneau : seize règles, trois domaines

Chaque domaine du panneau s’ouvre sur l’illustration de sa première règle, puis liste les suivantes avec leur réglage. Les valeurs affichées sont des exemples, pas le paramétrage d’un client.

Temps, absences et congés

La saisie et son contrôle, entité par entité, pays par pays. L’unité de saisie se choisit entre journée, demi-journée et heure (le panneau montre la demi-journée) ; dans le produit, elle se règle même activité par activité, jusqu’au quart de journée ou à l’unité d’œuvre. Les compteurs de congés sont définis par convention et par entité, et les jours fériés suivent un calendrier par pays d’implantation. Le contrôle entre CRA et absences peut être bloquant, se limiter à un avertissement ou être désactivé. Enfin, les rappels de saisie s’échelonnent : le collaborateur à J+2, son manager à J+5. Il n’y a pas de clôture de période qui verrouillerait la saisie : ce sont ces relances qui font rentrer les CRA.

Facturation et contrats

Un même moteur pour la régie, le forfait et tout ce qui est entre les deux. Le modèle de facturation se choisit entre régie, forfait, jalon et avancement. La TVA se règle par pays, par entité et par type de prestation. Pour les devises, le taux retenu est celui du jour de la facture, et il est conservé ensuite. Les conditions de règlement (échéance, pénalité, escompte) se définissent contrat par contrat. La numérotation des factures a un format et une séquence propres à chaque entité juridique. Et une alerte de dépassement se déclenche quand l’enveloppe franchit le seuil que vous avez fixé.

Projets, marges et achats

La rentabilité calculée en continu. La marge prévisionnelle est calculée dès le devis puis recalculée à chaque saisie. L’écart entre prévu et réalisé porte un seuil d’alerte, par projet et par activité. La validation des achats désigne le valideur selon le montant et le centre de coût. La refacturation des frais se fait avec marge, au réel ou au forfait, selon le contrat. Les règles d’affectation, enfin, fixent les critères qui font remonter un collaborateur sur une mission : compétences requises, disponibilité, priorité.

Régler, essayer, puis passer en production

Une règle se règle sans développement. Le paramétrage est compris dans votre abonnement, et les règles de gestion restent entre vos mains tant que l’on reste dans le paramétrage. Au-delà, le besoin se cadre avec nos équipes, et vous savez avant de vous engager s’il s’agit de paramétrage ou d’un développement chiffré.

Surtout, rien ne part en production à l’aveugle. Une modification de règle peut être déployée d’abord sur une base de test alimentée par vos données. Vous la manipulez dans vos conditions réelles : un CRA saisi sur une absence, une facture en devise, une note de frais au-dessus du seuil. Vous validez, ou vous demandez un ajustement.

Le paramétrage du socle fait partie du déploiement, qui se compte en semaines (moins d’un mois chez Zenika). Le reste s’affine ensuite, une fois que vous voyez le produit tourner sur vos données.

Une règle s’applique partout de la même façon

Une règle qui ne vaudrait qu’à l’écran serait une règle contournable. Dans AlibeeZ, les règles de gestion s’appliquent de la même façon à ce qui est saisi dans l’interface et à ce qui entre par l’API. Une écriture par l’API passe les mêmes contrôles, vos règles de gestion, vos circuits de validation, votre paramétrage : ce que l’écran refuserait, l’API le refuse aussi.

La conséquence est pratique. Si un outil maison pousse des temps dans AlibeeZ, le contrôle entre CRA et absences s’y applique comme pour un collaborateur. Et une règle que vous changez demain s’applique aux deux le même jour, sans rien à redéployer côté intégration.

Il en va de même entre vos entités. AlibeeZ gère plusieurs entités, devises et pays, chacun avec ses règles : la TVA, la numérotation, les jours fériés ou les compteurs de congés de la filiale belge ne sont pas ceux de la maison mère, et ils n’ont pas à l’être.

Ce que ça change

  • une spécificité de votre organisation devient un réglage, pas un projet de développement ;
  • un réglage s’essaie sur vos données avant d’arriver en production ;
  • la règle vaut pour tout le monde, à l’écran comme par l’API, dans chaque entité avec ses propres paramètres ;
  • les contournements tenus à côté, dans un tableur ou dans la mémoire d’une personne, disparaissent.

Pour aller plus loin : les règles disent comment le produit se comporte, l’article sur les workflows de validation montre comment elles s’enchaînent en circuits, et celui sur les modèles de facturation détaille le domaine facturation. Pour la question de fond, paramétrer ou développer, voyez notre analyse sur le paramétrage et le développement spécifique.

FAQ

Que veut dire « plus de 400 règles de gestion » concrètement ?

Ce sont des comportements paramétrables du produit : la façon dont un temps est saisi, le moment où une facture peut être émise, le seuil au-delà duquel une dépense demande un second valideur. Elles sont livrées et testées ; vous les activez et les réglez, vous ne les développez pas.

Peut-on modifier une règle soi-même ?

Oui, tant que l’on reste dans le paramétrage, qui est compris dans l’abonnement. Si votre besoin en sort, il se cadre avec nos équipes, et vous savez avant de vous engager s’il relève du paramétrage ou d’un développement chiffré.

Comment tester une règle avant de l’appliquer ?

La modification est déployée sur une base de test alimentée par vos données. Vous la manipulez dans vos conditions réelles, et rien ne part en production avant que vous l’ayez validée.

Les règles s’appliquent-elles aux données envoyées par l’API ?

Oui. Une écriture par l’API passe les mêmes contrôles que l’interface : vos règles de gestion, vos circuits de validation, votre paramétrage. Ce que l’écran refuserait, l’API le refuse aussi.