9 octobre 2026 – Release notes

À l’occasion de la sortie de version 26.41 de coog, nous avons le plaisir de vous présenter :

• L’arrivée de l’intelligence artificielle, avec l’analyse automatisée des pièces justificatives et l’aide à la décision en souscription médicale,
• De nouvelles capacités de pilotage de l’activité : indisponibilités des gestionnaires, échéances et priorités des tâches,
• L’extension de la loi Eckert aux prestations servies en rente.

Analyse documentaire automatisée avec Nexia de 10 Pourcent

Besoin : réduire le traitement manuel des pièces justificatives reçues.

Évolution

Coog s’ouvre à un nouveau fournisseur d’analyse documentaire, 10 Pourcent. À la réception d’une pièce justificative, Nexia détermine si le document correspond au type attendu et s’il est conforme.

Les résultats de l’analyse sont mis à disposition du moteur de règles, ce qui vous permet de définir votre propre politique de conformité.

Une règle d’exemple, Conformité document – Nexia (exemple), est livrée avec le module.

L’utilisation de ce fournisseur nécessite un abonnement 10 Pourcent.

---

Analyse de risque automatisée avec Klaimy

Besoin : accélérer l’instruction des dossiers de souscription médicale.

Évolution

Les analyses de risque du contrat peuvent désormais s’appuyer sur le service Klaimy. Au lancement d’une analyse de risque, coog constitue automatiquement un dossier Klaimy à partir des pièces médicales de l’assuré.

Le résultat est restitué à deux endroits :

• Une note de type Résultat Klaimy rattachée à l’analyse de risque, reprenant l’Évaluation globale du risque et l’Aperçu médical,
• Une pièce jointe Résultat d’analyse Klaimy contenant le rapport complet.

L’utilisation de ce service nécessite un abonnement Klaimy.

---

Coog Advance

Pilotage de l’activité

Contexte

Le traitement des tâches nécessite de connaitre la charge de traitement et les disponibilités des équipes afin de répartir l’activité.

Évolutions

Saisie des indisponibilités : une indisponibilité peut être rattachée à un utilisateur, à une équipe ou à tous les utilisateurs (jour férié par exemple).

Calcul du taux de disponibilité pour chaque utilisateur :

• Lors de l’affectation d’une tâche, leur disponibilité est affichée ;
• Un message alerte si l’utilisateur retenu n’a pas assez de temps pour traiter la tâche dans la journée.

Définition des priorités et des dates d’échéance pour chaque type de tâche :

• Création d’une règle d’évolution de la tâche permettant de faire évoluer automatiquement la priorité à l’approche de l’échéance,
• Définition de la charge de travail moyenne,
• Définition d’un délai de traitement maximal.

---

Suivi et extraction des réclamations ACPR

Contexte : mise en œuvre de la recommandation de l’ACPR pour le traitement des réclamations.

Évolutions

Création d’un nouveau champ d’activité permettant de saisir :

• La date d’accusé de réception,
• La date de réponse,
• Les mesures correctives,
• Les voies de recours.

Création d’un Batch de génération du reporting à destination de l’ACPR.

---

RGPD

Filigrane sur les pièces jointes

Besoin : mise en place de la préconisation de CNIL sur l’ajout d’un filigrane sur les documents sensibles.

Évolution

Ajout d’un filigrane paramétrable sur certains types de documents. Ce filigrane est ensuite ajouté sur la pièce jointe.

---

Modèles de courriers composites

Évolution : un modèle de courrier peut désormais agréger plusieurs modèles de courrier pour produire un document unique.

---

Norme SEPA

Évolution : ajout des versions pain.008.001.08 et pain.001.001.09.

---

Vue 360° des tiers

Évolution : ajout du numéro de contrat associé à chaque quittance.

---

Coog Back-Office

Réglementaire

Application de la loi Eckert aux prestations de type rente

Besoin : appliquer les pénalités et la revalorisation prévues dans le cadre de la loi Eckert aux prestations de type rente.

Évolution : l’application de la loi Eckert est désormais possible sur les prestations de type rente grâce à une règle livrée en standard.

---

Délais Eckert et Pacte paramétrables

Évolution

Les délais avant pénalité pour la loi Pacte et la loi Eckert sont désormais paramétrables. Ils peuvent être définis en jours comme en mois.

---

PASRAU : paiement des taxes URSSAF par virement

Besoin : faciliter la gestion des paiements de contributions sociales.

Évolution : génération d’un justificatif de mode de paiement qui permet aux équipes de saisir manuellement le virement.

---

DSN : ajout d’un Batch de purge des amorces des déclarations

Évolution : création d’un Batch permettant de purger les amorces rattachées aux déclarations DSN au-delà d’une durée de rétention paramétrable.

---

Contrats

Cotisations

Exonération de primes créées automatiquement à l’indemnisation

Besoin : pouvoir gérer les garanties d’exonération de prime en automatique.

Évolutions :

• Ajout d’une règle d’exonération à une prestation de type période ou rente,
• À la validation d’une indemnisation, l’exonération correspondante est créée automatiquement sur le contrat et l’éventuel trop-perçu de cotisation est remboursé automatiquement.

---

Contrats collectifs

Bordereaux d’appel

Neutralisation des bordereaux d’appel collectif

Besoin : pouvoir neutraliser les bordereaux d’appel d’une entreprise.

Exemple

Les personnes morales couvertes par le groupe de population “Loi Evin” ne doivent pas générer de bordereaux d’appels de cotisations. Leurs cotisations seront individuelles sur un contrat lié. Il est donc nécessaire de neutraliser le bordereau d’appel.

Évolutions

• Action manuelle sur chaque bordereau pour les neutraliser au cas par cas.
• À la souscription, possibilité d’indiquer qu’aucun bordereau d’appel ne devra être généré pour tous les affiliés d’une population donnée.
• Déclaration de périodes de neutralisation sur les sociétés filles. Les bordereaux sont générés directement à l’état “Neutralisé”.
• Création d’un *Batch* de dé-neutralisation permettant de repasser les bordereaux à leur état d’origine si une date de fin de neutralisation avait été positionnée.

---

Création d’un avenant de mise à jour des données complémentaires sur les garanties à configuration incomplète

Évolution

Création d’un avenant permettant de compléter les données complémentaires des garanties souscrites d’une population lorsque la configuration est incomplète.

Une fois la saisie réalisée, la configuration des prestations est marquée comme terminée.

---

Amélioration de l’avenant ‘“lier les filiales”

Évolution : lors du rattachement de filiales à un contrat, la date d’effet saisie est désormais reprise automatiquement dans les écrans de gestion des interlocuteurs de cotisation et de prestation.

---

Sinistres

Refonte de l’intégration des flux des bordereaux de paiement pour le versement des Indemnités journalières – BPIJ

Besoin : mettre en place une mécanique d’amorçage permettant de rejeter certaines lignes du fichier sans rejeter l’intégralité et améliorer le suivi.

Évolutions

L’intégration des périodes BPIJ se fait en deux temps :

• Le chargement des amorces de périodes BPIJ lit les fichiers reçus,
• Le traitement des amorces de périodes BPIJ transforme les amorces valides en BPIJ.

Un nouveau point d’entrée permet de consulter les amorces avec :

• Le détail de l’en-tête,
• Le détail des périodes.

Ce point d’entrée permet également de recycler ou de rejeter la ligne.

---

Saisie d’une indemnisation malgré une décision d’analyse bloquante

Besoin : pouvoir saisir les indemnisations lorsqu’une analyse médicale est en attente.

Évolutions

Lorsqu’une demande de décision bloque le calcul d’une indemnisation, l’utilisateur peut créer l’indemnisation au statut brouillon en attendant la finalisation de l’analyse médicale.

À la finalisation de la décision :

• Si la décision est bloquante, les indemnisations concernées sont rejetées,
• Sinon les indemnisations brouillons sont calculées et ordonnancées.

---

Prestations mono-bénéficiaire

Évolution

Une prestation peut désormais être paramétrée en mono-bénéficiaire : l’ajout d’un second est refusé, la répartition est automatiquement fixée à 100 % en pourcentage.

---

Santé

Protection sociale

Amélioration des avenants de changement de protection sociale et de changement de régime spécial

Évolutions

• Avenant de changement de régime spécial : possibilité de renseigner la qualité de travailleur non salarié ainsi que la période de l’exercice fiscal.
• Avenant de changement de protection sociale : le numéro d’organisme alimente automatiquement l’organisme et le régime.

---

Noémie

Rapprochement des retours Noémie par les mouvements

Évolution : permettre de rapprocher les flux sur le code mouvement si le rapprochement par l’image n’a pas pu être réalisé.

---

Robustesse de la génération du flux 408

Évolution

Le Batch de génération des images 4xx ne s’interrompt plus lorsqu’une erreur est remontée. L’image est écartée du traitement et peut être recyclée depuis le point d’entrée de pilotage Noémie.

---

Suivi des Noémisations

Évolutions : la date d’envoi de l’image 4xx est ajoutée sur les Noémisations.

---

Réactivation d’un contrat

Évolution : ne pas envoyer de mouvement Noémie si le contrat est résilié puis réactivé le même jour.

---

Tiers

Enrichissement du fonctionnement des identifiants de tiers

Évolution : les types d’identifiant peuvent être désactivés et sont restreints à certains types de tiers (Personne, Entreprise, Configuration).

---

Documents et courriers

Images configurables pour les courriers

Besoin : faciliter la personnalisation des courriers grâce à l’ajout des images.

Évolution : ajout de deux types d’image (logo et signature) pour les utilisateurs, les produits, les distributeurs afin de les utiliser sur les modèles de courriers.

---

Extensions de fichiers autorisées par type de document

Évolution : l’ajout d’une pièce jointe est refusé lorsque l’extension du fichier n’est pas autorisée.

---

Tri sur les modèles de courriers

Évolution : dans l’assistant d’édition d’un courrier, il est désormais possible d’afficher les courriers dans l’ordre des séquences paramétrées.

---

Moteur de règles

Permettre de rechercher et remplacer dans le moteur de règles

Évolution : à l’image de ce qui a été mis en place pour les fichiers ODT et ODS, il est possible de rechercher les valeurs des fonctions du moteur de règles et de les remplacer par de nouvelles valeurs.

---

Contrôle des paramètres d’une règle

Évolution : permet d’identifier les éléments complémentaires déclarés dans le contexte mais jamais utilisé dans l’algorithme.

---

Ajout d’une fonction du moteur de règles retournant le détail du calcul de l’indemnisation

---

Ajout de deux fonctions du moteur de règles retournant le code IDCC du souscripteur et celui de l’assuré

---

Ajout d’une fonction du moteur de règles permettant de déterminer si une date est le dernier jour du mois

---

Ajout des usages d’une table

Évolution : depuis les tables, création d’un ou plusieurs liens vers les règles sur lesquels elles sont paramétrées.

---

Noyau technique

Nouveau mode de configuration des exports

Évolution

Chaque modèle peut désormais exporter tous les champs. L’utilisateur a, ensuite, la possibilité de supprimer les champs non souhaités.

À noter, la configuration initiale permettant de d’exporter seulement les champs listés est conservée.

---

Estimation de la durée d’un Batch

Évolution : afficher la durée estimée restante pour un Batch ainsi que la date de fin prévisionnelle via l’action “Estimer la durée restante“.

---

Analyse antivirus des pièces jointes

Évolution

Brancher un service externe d’analyse antivirus sur les fichiers déposés dans coog. Ces derniers peuvent désormais être analysés par un antivirus avant enregistrement.

---

Agrégat d’erreur

Besoin : pouvoir identifier rapidement les erreurs qui ont une cause commune trans-environnements (recette et production par exemple).

Évolution

Ajout d’un point d’entrée “Agrégats d’erreur” permettant de consulter :

• L’erreur,
• Le nombre de fois qu’elle a été rencontrée,
• La date de 1re occurrence,
• La date de dernière occurrence.

---

Donnée complémentaire de type Texte

Évolution

Mise en place d’un nouveau type de données complémentaires permettant de saisir du texte et réaliser une mise en page lisible. Ce type de donnée complémentaire est également disponible dans les API.

---

Reprise de données

Nouveaux migrateurs

• Migrateur de taux de commission personnalisés
• Migrateur de demandes de documents
• Migrateur des tables d’implémentation
• Migrateur des situations fiscales
• Migrateur des données de Noémisation

---

Enrichissements des traitements de migration existants

Migrateur des quittances contrat : ajout des quittances de frais de rejet.

Migrateur des contrats collectifs :

• Ajout des identifiants externes,
• Ajout des fréquence de paiement.

Migrateur des prestations :

• Ajout des informations de versement des prestations, du mode de paiement et de la fréquence d’indemnisation,
• Ajout des revalorisations et des pénalités Eckert,
• Ajout de la date de reprise de gestion.

Migrateur des comptes bancaires : ajout de la distinction de l’IBAN de cotisation et de l’IBAN de prestation.

Migrateur des personnes morales : ajout du mode de communication de gestion de contrat.

Migrateur des garanties : ajout du champ “Configuration des prestations terminée”.

Migrateur des personnes physiques :

• Ajout du mode de communication de gestion de contrat,
• Ajout du mode d’envoi des décomptes almerys,
• Ajout du mode d’envoi des courriers de gestion almerys.

---

Identification des objets migrés

Évolution

Un utilisateur dédié est désormais créé et utilisé par les reprises. Tous les objets issus d’une migration portent cet utilisateur comme créateur, ce qui permet de les distinguer immédiatement des objets saisis en gestion.

---

Ergonomie

Identification de l’environnement

Besoin : permettre de détecter rapidement si un utilisateur est connecté à un environnement de test et de connaître sa date de connexion.

Évolution

Un bandeau est ajouté en haut pour spécifier qu’il s’agit d’un environnement de test. Le bandeau passe au rouge sir la date de connexion est personnalisée.

---

Coog API

Identités et habilitations

Écrans d’administration des identités API

Besoin : dissocier la gestion des utilisateurs de la gestion des API afin de faciliter cette dernière.

Évolution
Les identités API ne sont plus reliés aux identités de coog. Il est désormais possible d’associer des profils à des identités API.

---

Profils multiples sur les identités API

Évolution

Une identité API peut se voir attribuer un ou plusieurs profils. Les droits accordés correspondent à l’ensemble des droits API de tous les profils rattachés.

---

Plafonnement des identités à clé API

Évolution

Le nombre d’identités API utilisant une clé API est désormais plafonné. Au-delà du plafond, la création ou la bascule d’une identité vers ce mode d’authentification est refusée. Lorsqu’il ne reste que deux places ou moins, un avertissement prévient l’administrateur.

---

Authentification par lien de connexion

Évolution

Un nouveau mode d’authentification des identités API est disponible : le lien de connexion. Depuis la fiche d’une identité, l’assistant Demander un lien de connexion génère un lien à usage unique et à durée de vie limitée. Ce lien est envoyé par courriel grâce à un modèle livré en standard. Un menu Liens de connexion permet de suivre les liens émis et leur statut.

---

Pilotage du mode de Debug des appels API

Évolution

Un mode de Debug est disponible sur les API : lorsqu’il est actif, les réponses en erreur embarquent des informations de diagnostic détaillées. Il se pilote au niveau de chaque identité API.

---

Suppression des codes numériques des erreurs API

Évolution : les codes numériques des erreurs API ont été supprimés au profit des seuls codes textuels, plus lisibles et stables.

---

API GraphQL

Ré-écriture de l’API GraphQL Référentiel

Évolution

Le schéma GraphQL permettant d’interroger le référentiel de paramétrage de coog a été ré-écrit en utilisant la nouvelle version de notre *Framework* interne GraphQL. Certaines API répondant à un besoin similaire (recherche de banques / organismes prêteurs / pays / etc.) ont été supprimées, les fonctionnalités correspondantes ayant été intégrées dans ce nouveau schéma.

---

Pagination des listes

Évolution

Les listes exposées en GraphQL peuvent désormais être paginées : les résultats sont parcourus page par page.

---

Authentification JWT des requêtes historiques

Évolution

Les requêtes GraphQL historiques s’authentifient désormais par jeton JWT, au même titre que les API v3. L’identité appelante et le contexte de la requête sont propagés jusqu’au traitement.

---

Consultation des pièces jointes

Évolution

Les pièces jointes peuvent être consultées via GraphQL : métadonnées (nom, taille, date), contenu ou lien de téléchargement.

---

Exposition des données complémentaires

Évolution :

La définition des données complémentaires est exposée en GraphQL : type, libellé, aide, valeur par défaut, valeurs possibles et conditions d’affichage. Un applicatif tiers peut ainsi construire dynamiquement ses écrans de saisie et faire contrôler les valeurs soumises.

---

Schéma d’administration réservé à la passerelle

Évolution

Un schéma GraphQL d’administration, réservé à la passerelle d’API, permet de consulter et de gérer les identités API. L’identité appelante est portée par le jeton JWT, et son contexte (réseau de distribution, canaux, distributeurs) est restitué afin de router les appels suivants.

---

Dépôt de fichiers temporaires

Évolution

Les API peuvent déposer des fichiers temporaires. Un jeton d’envoi est délivré, le nom de fichier et le type MIME sont contrôlés au dépôt, et un traitement de purge supprime automatiquement les fichiers non consommés.

---

Avenants par API

Enrichissement des avenants disponibles par API

Création d’une API d’avenant permettant de modifier les données complémentaires de contrat

Création d’une API d’avenant pour mettre à jour les données de contact :

• E-mail,
• Téléphone.

Création d’une API d’avenant permettant la modification des coordonnées bancaires