Transcription

• Speaker #0

  Les Aventuriers de la DSN, un podcast GERESO animé par Amandine Lecomte et Denis Prodhomme.

• Speaker #1

  Bonjour et bienvenue dans Les Aventuriers de la DSN. Moi c'est Amandine Lecomte, consultante formatrice en droit social Paie et DSN depuis 2008.

• Speaker #2

  Et je suis Denis Prodhomme, consultant Paie et DSN chez GERESO. Et nous sommes toujours aussi passionnés, alors certains diraient obsédés, ou alors hantés, ou alors obnubilés par ce sujet.

• Speaker #1

  Dans le premier épisode, on a parlé des contrôles DSN avec Monique, responsable paie adjointe en cabinet comptable. Si vous ne l'avez pas écouté, allez-y, c'était plein de bons réflexes concrets.

• Speaker #2

  Aujourd'hui, on change de perspective, on reste sur le thème des anomalies DSN, mais on va regarder le problème depuis l'autre côté du miroir, celui de l'éditeur de logiciels. Parce que quand on a une DSN qui part en erreur, il y a toujours quelqu'un qui a pensé, imaginé, créé, recété. et travailler sur tous ces cas de figure en amont.

• Speaker #1

  Et notre invité du jour, c'est quelqu'un qui a justement décidé de tout repenser depuis le départ. Thomas De Priestere est le fondateur du logiciel de paye Linc. Il nous rejoint pour parler du comment on construit un outil qui lutte nativement contre les anomalies DSN et qui place l'utilisateur au centre, quelqu'un qui essaye de faire du logiciel de paye un véritable partenaire utile du gestionnaire.

• Speaker #2

  Mais avant de lui passer la parole... On a notre petit rituel sonore.

• Speaker #1

  Bon, maintenant, vous connaissez le rituel, on passe aux choses sérieuses.

• Speaker #2

  Bon, Amandine, on attaque la partie technique, le sujet du jour, les anomalies bloquantes et les signalements en DSN. Et pour bien comprendre de quoi on parle, il faut commencer par un mot qu'on entend souvent, mais qu'on n'explique pas toujours. Alors, le cahier technique, c'est notre... livre de chevet à nous, mais je ne suis pas sûr que tout le monde soit d'accord avec ça. Donc on va parler un petit peu chinois, accrochez-vous.

• Speaker #1

  Le cahier technique, tu as raison, c'est un peu notre livre de chevet. C'est finalement le dictionnaire de la DSN. Aujourd'hui, la DSN, il faut le voir comme une nouvelle langue. Tu parles de chinois, moi j'appelle la langue DSN, c'est un peu la même chose. C'est une langue avec ses propres règles. Et si on ne maîtrise pas la langue, c'est assez difficile. de comprendre. Et ce dictionnaire de la DSN, c'est le fameux cahier technique qui va être le document de référence qui va décrire la norme dans les moindres détails. Les rubriques, les formats attendus, les règles de cohérence, les contrôles, beaucoup de choses y est, on va dire tout y est ou presque.

• Speaker #2

  Oui, effectivement, tout y est, mais pas toujours de manière très lisible. Parce qu'avant tout, c'est un document qui a été écrit pour les informaticiens. pour les intégrateurs, pour les gens qui vont construire vos modules DSN dans vos outils. Et ce n'est pas forcément écrit pour des gestionnaires paye ou alors pas pour tous les gestionnaires paye, peut-être ?

• Speaker #1

  Alors, c'est certain, ce n'est pas écrit pour les gestionnaires de paye qui sont câblés pour faire de la paye et qui ont fait de la paye toute leur vie. Parce que c'est clairement là que le bas blesse. Parce que quand une anomalie nous remonte dans le logiciel, le message d'erreur affiché, c'est souvent une copie quasi conforme du message affiché dans le cahier technique avec ses codes, avec ses références de rubrique, avec son langage très technique. CRE 11, CCH 12, bon, ça parle pas à grand monde tout ça.

• Speaker #2

  Justement, on va en parler un petit peu parce que dans le cahier technique, les contrôles ont des noms de codes. Il y a plusieurs types de contrôles. Alors, le premier qu'on aborde là aujourd'hui, le CSL. le contrôle de syntaxe lié à la rubrique. C'est le plus basique. Est-ce que la donnée saisie a le bon format ? Un SIRET à 14 chiffres, une date au bon format, donc une date en DSN à 8 chiffres avec jour, jour, mois, mois, année, année, année, année. Si ce contrôle échoue, c'est bloquant. La déclaration entière est rejetée.

• Speaker #1

  Et ce qui est logique puisque je n'ai pas mis dans la case ce qui était attendu. Dans la même logique, justement, on a le contrôle CCH, contrôle de cohérence. Là, on est quelque chose de plus subtil en réalité, quelque chose de beaucoup plus subtil. On va vérifier que plusieurs rubriques de la DSN sont cohérentes. Mais on ne va pas forcément nous dire où est l'erreur. On va juste nous dire que vous avez une incohérence dans votre DSN. Par exemple, un CDD qui démissionne. Un CDD, ça ne démissionne pas. Donc, on va nous dire, vous choisissez, soit c'est un CDD, soit c'est une démission. mais ce n'est pas les deux en même temps.

• Speaker #2

  Et c'est ça qui est un peu brutal dans le système. Une seule anomalie bloquante et c'est tout le fichier qui part à la poubelle. Ne le mettez pas à la poubelle, s'il vous plaît. Il ne partira pas vers les organismes.

• Speaker #1

  Oui, donc il ne sert à rien en gros.

• Speaker #2

  Non, il ne sert à rien.

• Speaker #1

  Dans la suite, on a aussi les contrôles CRE. CRE, moi j'aime bien les appeler. Contrôles sur des référentiels externes. Ces contrôles sur des référentiels externes vont vérifier que les données correspondent à des listes officielles extérieures à la norme elle-même. Typiquement un code. postale ou un code convention collective. Si vous mettez un code dans votre DSN qui n'existe pas sur le référentiel externe qui prévoit les codes convention collective ou les codes postaux, votre DSN ne partira pas puisque le code que vous avez envoyé n'existe pas. Je fais un point rapide sur un autre code anomalie CME. Alors ça j'ai envie de dire quand vous l'avez celui-ci vous pouvez pas passer à côté. Pourquoi ? Parce que ça veut dire tout simplement que Le sirène déclarant, il n'est pas reconnu par les organismes, vous ne pouvez tout simplement pas envoyer votre DSN, on ne sait pas qui vous êtes.

• Speaker #2

  Et enfin, on va parler d'un contrôle qu'on aime bien, nous, c'est le CID, donc pas le CID de Corneille, le contrôle interdéclaration. Ceux-là sont un peu à part parce qu'ils ne sont pas forcément bloquants. Ils vérifient la cohérence dans le temps d'une DSN à l'autre. Une déclaration annulée en place doit bien annuler quelque chose qui existe, et si ce n'est pas le cas, c'est bloquant. Ça paraît évident, mais c'est une source d'erreurs fréquentes. À l'inverse, si le problème se situe par exemple dans une incohérence entre deux DSN. Par exemple, un salarié non cadre qui est passé cadre sans qu'on indique la date de changement. C'est gênant pour l'agir carco, pour calculer valablement les cotisations, mais ce n'est pas bloquant. De même qu'un contrat qui est censé continuer sur la durée, on peut avoir un joli CID. Voilà, votre salarié était présent le mois précédent. on ne le retrouve pas ce mois-ci, alors qu'il n'y a pas eu de fin de contrat présenté.

• Speaker #1

  Tu as tout à fait raison. Ça, c'est quelque chose qu'on rencontre assez souvent. La DSN, elle raconte une histoire. Et parce que la DSN raconte une histoire, si mon salarié ou mon agent disparaît de la DSN, je dois avoir une raison à sa disparition. Et une raison à sa disparition, c'est une sortie. Pour finir, dans ces anomalies du cahier technique, on a les SIG, consignes de signalement, consignes de remplissage. Ce n'est pas bloquant non plus, mais c'est finalement les anomalies les plus intéressantes. Pourquoi ? Parce qu'elles donnent des alertes. Elles nous disent « Attention, vous nous avez renseigné ça. Est-ce que vous êtes vraiment sûr qu'il fallait nous renseigner ça ? » Un exemple tout simple, vous pouvez envoyer un CDD sans avoir indiqué de motif de recours. Ce n'est pas bloquant. La DSN vous signale « Est-ce que vous êtes sûr que vous m'envoyez un CDD sans motif de recours ? » Moi, je ne suis pas sûr qu'un CDD, ça puisse passer sans motif de recours. Mais c'est un signalement, ça passe tranquillement.

• Speaker #2

  Bon, on essaye de résumer. Donc, CSL, CCH, CRE, CME, c'est bloquant. SID, SIG, c'est non bloquant, mais ça mérite attention parce que ça cache régulièrement des erreurs de fond.

• Speaker #1

  Très, très souvent, tu as raison. Et ça, c'est le vrai problème du quotidien. C'est quand le logiciel affiche un message d'erreur, comme c'est souvent du copier-coller du cahier technique, Ça nous donne des choses du style « CCH12, la rubrique S21G0040011 est renseignée avec la valeur 12 ou 20, implique que S21G0040012 soit inférieure ou égale à 31 » . Et ça, j'ai envie de dire, pour beaucoup de gestionnaires de paye, ça ne veut rien dire du tout.

• Speaker #2

  Le gestionnaire paye se retrouve avec ce message qu'il doit tenter de déchiffrer. Donc, ce qu'on rencontre régulièrement, c'est que… Et voilà. Il referme sa DSL, il tente d'envoyer un grand message au secours, mais c'est tout. Parce qu'il a l'impression de tomber plus sur un code secret qu'autre chose. Donc ça va nous permettre ensuite d'enchaîner avec notre invité, parce que c'est ce qu'il a voulu améliorer dans son logiciel.

• Speaker #3

  Cahier technique de la DSN. Alors, le cahier technique de la DSN, c'est des lignes de code. C'est un gros sommaire qu'on déroule, qu'on déroule. Il y a beaucoup de choses. Non, ça ne me parle pas. Franchement, non, ça ne me parle pas du tout même.

• Speaker #1

  C'est vrai que le cahier technique de la DSN, ça peut paraître être un truc un peu incompréhensible. Et c'est exactement pour ça qu'on fait ce podcast. Et vous, en un mot, c'est quoi pour vous la DSN ? Allez, écrivez-nous, on est curieux. Thomas, bienvenue. Merci de nous rejoindre dans les Aventuriers de la DSN. Je te laisse te présenter.

• Speaker #0

  Bonjour à tous les deux. Merci de votre accueil. Je vais me présenter très rapidement. Moi, c'est Thomas De Priestere, cofondateur de Linc. Ça fait quasiment 15 ans que je travaille et que je travaille dans la paye. Je suis tombé dedans un peu par hasard et je me suis pris de passion tout de suite pour le sujet. Ma première expérience est très rapide. J'étais gestionnaire de paye en cabinet et je suis assez rapidement passé côté éditeur de logiciel. Et ce passage côté éditeur de logiciel, c'est ce qui va être drôle pour... notre moment ensemble, c'est qu'il s'est fait au moment où on s'est lancé sur la DSN en France. J'ai commencé à travailler chez un éditeur en 2014, au moment de la DSN phase 1, et j'ai accompagné cet éditeur pendant deux ans, la phase 1, la phase 2, la phase 3. Donc ça, c'était la petite anecdote pour commencer. Et aujourd'hui, j'ai cofondé Linc, donc il y a deux ans. Linc, c'est un logiciel de paye à destination des pros de la paye, donc des cabinets de paye ou des cabinets comptables. À côté de ça, je suis aussi passionné d'histoire et je fais pas mal de parallèles entre la paie et l'histoire. Je le vois vraiment comme pas tant le métier en lui-même, bien qu'eux, mais surtout l'environnement, les changements constants, la complexité qu'il peut y avoir et ce que ça raconte en fait aussi de la société française et de l'impact que ça a. Le bulletin de paie qu'on résume à un petit papier qu'on a tous sous les yeux, c'est ce qui donne droit à plein de choses, la retraite, du chômage et autres. Et donc avec ce regard-là, j'ai une vraie passion pour la paie. C'était une évidence à un moment donné de me lancer et d'essayer de créer un logiciel de paye ou de co-créer en tout cas, parce que je ne suis pas seul à l'avoir fait, évidemment. Et c'est une évidence d'essayer de faire le meilleur outil pour les gestionnaires de paye. Donc, on construit un outil pour eux et avec eux. On le co-construit beaucoup avec nos utilisateurs.

• Speaker #1

  Merci. Et c'est vrai que c'est quelque chose qu'on apprécie chez Linc, ce côté co-construction avec les utilisateurs, parce que c'est souvent ce qui nous relève. parfois ils ont l'impression d'être un peu démunis vis-à-vis de leur éditeur, et ça c'est vraiment une très bonne nouvelle. Toi en tant qu'éditeur, tu es en première ligne face à cette complexité, face à ces évolutions, comment tu l'apprivoises, comment tu la retranscris ce cahier technique pour que l'utilisateur n'ait pas à le subir, pour qu'il n'ait pas forcément à subir la norme ?

• Speaker #0

  Il y a deux réponses dans cette question. La première chose, comment on l'apprivoise ou même comment on l'a apprivoisé dès le départ ? Bon, ça, c'est beaucoup de... technique, c'est beaucoup d'outils, beaucoup de développement, pour essayer d'être au plus près aussi de la veille, d'être hyper réactif, parce qu'on pense souvent à la veille sociale, l'impact d'une nouvelle loi sur le bulletin, on oublie souvent l'impact sur la déclaration. Ce qu'il ne faut pas oublier, c'est qu'une paye juste, un bulletin juste, ne veut pas dire qu'il n'y aura pas de redressement demain, parce qu'en fait, ce qui est regardé maintenant, c'est la DSN, ce n'est plus le bulletin. Donc on est aussi très proche de cette veille normative. Et de comment on a essayé d'automatiser aussi le plus possible ce décodage de règles. Et donc, on a créé des outils qui viennent nous comparer les différentes normes, même si, pour le coup, la norme elle-même donne des outils et des comparaisons quand il sort une nouvelle norme. Et ça, après, on le traduit dans un langage métier qui est le nôtre pour que l'outil soit le plus rapidement possible, juste et à jour. Mais il y a une autre réponse aussi qui est comment on le retranscrit. Et comment on le retranscrit, c'est comment ça se traduit côté utilisateur. Et on en parlera certainement, mais l'utilisateur, on ne va pas lui exposer, vous parliez tout à l'heure... de codes de contrôle, on ne va pas lui exposer ces codes-là quand il y a une anomalie. Il est complètement perdu. Et même s'il devrait peut-être plus s'intéresser aux cahiers techniques, on ne va pas lui demander de s'intéresser aux cahiers techniques. Ce n'est pas concevable de lui demander de mettre le nez dedans. Donc, on est aussi sur la retranscription de cette nouvelle norme dans un langage, c'est tout bête, mais français, adapté à l'outil et au métier.

• Speaker #2

  OK, très intéressant. Est-ce que tu peux nous donner un exemple concret ? Parce que sur les anomalies dont on a parlé tout à l'heure...

• Speaker #0

  Oui.

• Speaker #2

  quand on était en mandarin, niveau plus plus là. CCH, CSL, généralement, nous, on est en formation régulièrement. Les stagiaires nous regardent avec des grands yeux. Comment est-ce que vous avez travaillé dessus pour tenter de le retraduire et que ce soit à peu près digérable pour un gestionnaire paye ?

• Speaker #0

  Déjà, on ne va pas leur exposer que c'est une erreur CCH 12 où ça paraît bête, mais ça aurait été facile. On a juste à reprendre l'erreur, on l'expose, et démontez-vous. On ne l'a pas fait comme ça. Donc, on expose l'erreur, oui, mais dans un langage compréhensible. C'est quoi le problème ? L'erreur CCH12 que vous avez mentionné, elle va dire, est-ce que mon salarié en forfait jour, il a un temps qui est supérieur à ce qui est possible dans un mois ? Voilà ce qu'il faut dire. En fait, là, je l'ai retranscrit avec un langage simple. S'il y a une erreur, ça veut dire qu'il y a plus de jours que ce qui est possible dans un mois.

• Speaker #1

  Et du coup, pour éviter d'envoyer des SN avec des anomalies bloquantes, Est-ce que Linc intègre des blocages natifs, des contrôles qui interviennent dès la saisie, avant même que la DSN soit générée, pour éviter justement ces anomalies ?

• Speaker #0

  Oui, c'est aussi au-delà d'exposer l'erreur, on essaye de la prévenir le plus possible. Alors déjà, il y a envoyer une DSN qui contient des anomalies, intégrer des outils de contrôle pour contrôler sa DSN avant de l'envoyer, être sûr qu'elle parte sans anomalies. Et au-delà de ça, il y a aussi, quand on la génère, éviter qu'elle ressorte une première fois avec plein d'anomalies à corriger. Et ça, c'est des choix de conception fondamentales qu'on a fait au début. C'est un peu un sujet de philosophie même dès le départ. On a créé un outil avec une norme DSN qui existait déjà. C'est aussi notre avantage. On n'a pas de dette de 20 ans de logiciel derrière. Donc l'outil est construit en conséquence. Je vous donne un autre exemple d'anomalie qui peut arriver. L'anomalie sur le numéro de sécu, avec la cohérence avec la date de naissance. Le salarié, on ne le crée pas en DSN. On le crée dans le logiciel de paye. Et après, on l'a dans la DSN. Donc ce contrôle, si on le met au moment où on crée le salarié, on n'aura pas de problème en DSN. Et donc on prévient comme ça tout un tas d'anomalies.

• Speaker #2

  La norme DSN évolue régulièrement. Donc le cahier technique est mis à jour. Il y a les nouvelles règles qui apparaissent. Comment est-ce que vous gérez ça au niveau de votre équipe ? Côté développement, est-ce que c'est une contrainte lourde ? Sans nous révéler tous les secrets de fabrication.

• Speaker #0

  Oui, je ne vais pas vous ouvrir toute la recette de notre outil. Mais je vais être honnête, ce sujet de veille, c'est une contrainte. Et c'est normal, mais c'est aussi pour ça qu'on s'est lancé dans un logiciel de paye. C'est aussi pour ça que j'aime la paye. C'est parce que c'est contraignant, c'est compliqué. Et donc cette veille, que ce soit sur de la paye ou de la DSN, elle est complexe parce qu'elle est très étendue. Elle est parfois à multiples vérités aussi. Et c'est pour ça que chez Linc, on a une grande majorité de notre effectif qui est une population de développeurs et qui a créé des outils pour faire la veille la plus automatisée possible, la décoder très facilement, la développer, mais surtout intégrer tout un tas de tests et des tests automatiques. Donc au moindre changement qu'on peut avoir dans la législation ou dans la norme DSM, on va avoir des milliers de points de contrôle, de tests qui vont tourner au moment où on injecte le changement pour être sûr qu'il n'y ait pas de régression. Ou s'il y en a une, s'il y a un changement, qu'il soit volontaire et normal parce qu'il est causé par la nouvelle norme. Et donc tout ça, on l'a automatisé dès le départ. On a mis beaucoup de temps à développer ces outils au départ pour avoir un outil qui soit le plus sûr possible.

• Speaker #1

  Merci. C'est vrai que tu nous as mentionné dans ta présentation que tu mettais l'utilisateur vraiment au cœur de ton positionnement. C'était vraiment votre marque différenciante, j'ai envie de dire. Concrètement, comment les gestionnaires de paie vont participer à faire évoluer Linc ? Est-ce qu'il y a un processus formalisé, un comité, des bêta-testeurs ?

• Speaker #0

  Oui, on a tout ça. C'est drôle, juste avant, un peu en off, on en parlait et on connaît des personnes en commun. Et c'était toute la volonté quand on a commencé à créer Linc. c'était de créer un logiciel de paye avec les utilisateurs. Moi, j'ai plein de convictions. Ça fait 15 ans que je bosse dans la paye. J'ai plein de convictions de ce que doit être la paye et la DSN. Mais mes convictions seules, elles ne servent à rien parce que je suis biaisé par ce que j'ai vu et découvert et ce qui est assez restreint aussi. On crée un outil pour eux. Donc, c'est aux utilisateurs de nous dire ce dont ils ont besoin. Et ça, on a mis en place pas mal de choses. Alors oui, on prend en compte tous ces feedbacks après chaque période de paye, par exemple. on interroge les utilisateurs qui utilisent l'outil on passe du temps avec eux, ça fait un an et demi qu'on est en production, ça fait un an et demi ou tous les mois on passe du temps avec eux après une paye pour savoir ce qui s'est bien passé pour savoir où était leur point de douleur, est-ce qu'on doit automatiser et ils priorisent avec nous la roadmap produit notamment avec Virginie chez nous qui dirige ce produit elle passe énormément de temps avec eux et un autre exemple, je pense qui schématise beaucoup l'approche qu'on a chez Linc c'est que tous les salariés, peu importe sur quoi ils bossent, que ce soit un développeur, un sales quelqu'un au marketing ou au support, passe à minima une heure par mois avec un gestionnaire de paye pour observer son métier et savoir ce qu'il fait.

• Speaker #2

  Très bien. Pour finir sur la partie technique, si tu pouvais changer une chose dans le cas technique, c'est une question complexe quand même.

• Speaker #0

  Je pense que c'est sur... Alors bon, là, c'est mon regard d'éditeur qui va intervenir. J'aimerais parfois plus d'exemples. Je m'explique. C'est très bien d'annoncer une nouvelle norme, d'annoncer comment ça doit se passer, ou même une norme existante dans le cahier technique. Il faut la digérer, il faut déjà la comprendre et la digérer, savoir comment on va la mettre en pratique. Et puis après, nous, on va la tester, on va voir si ça ressort correctement. Je trouve parfois que le cahier technique manque d'exemples concrets. Alors, il y a plein de fiches qui se complètent à la norme, mais ce sont des fiches en texte, en format texte. Moi, j'aimerais qu'ils puissent mettre parfois des DSN tests. Il génère un fichier texte, il nous le donne et on peut l'exploiter pour voir comment ça ressort, quelle est l'arborescence qu'ils ont utilisée et qu'on puisse reproduire le même modèle. C'est ça qui me manque aujourd'hui.

• Speaker #2

  Merci beaucoup. On a terminé sur cette partie technique. On va tout de suite passer, après la pause, sur la partie vécue.

• Speaker #1

  Donc, on va passer maintenant à ton vécu personnel. Toi, Thomas, tu n'es peut-être pas forcément gestionnaire de paye à la base. Tu es entrepreneur. Ça va être quoi ta première rencontre avec la DSN ? Le moment où tu as réalisé, dans quoi tu t'embarquais ?

• Speaker #0

  Alors, j'ai été gestionnaire de paye pas longtemps, mais c'était quand même mon premier job. Et c'est vrai que je ne le suis plus. J'ai deux rencontres avec la DSN, je vais aller assez vite sur la première. La première, je vous l'ai dit, c'était en 2014, quand tout le monde a rencontré la DSN, j'étais déjà là. Donc je l'ai vue à ce moment-là, mais moins dans sa complexité, moins au travers du cahier technique, plus au travers d'un outil qui existait déjà. La deuxième anecdote, c'est peut-être celle-là qui fera le plus de sens, c'est quand j'ai mis mon nez dans le cahier technique pour Linc. Et je pense que l'élément marrant là-dedans, c'est que la première fois où j'ai ouvert ce cahier technique, qui faisait, je crois, en 2024, 168 pages de mémoire. Je l'ai ouvert. Je m'étais mis un matin en me disant, allez, je commence par ça. Ce n'était pas le plus réjouissant de ma journée, mais je commence par ça. Je suis resté cinq minutes dessus à le balayer, sans regarder trop ce qu'il y avait dedans. Je ne comprenais rien de ce qu'on m'exposait. Je l'ai fermé en me disant, ce n'est pas possible. Je ne peux pas passer ma journée à lire ce document. Et donc, on a pris la chose à l'inverse. J'ai pris un développeur avec moi. On a essayé de voir comment on pouvait extraire de l'info. un peu cruciale, et puis y aller progressivement comme ça. Mais alors, la première fois que j'ai ouvert le PDF, franchement, j'ai pris peur, fermé l'ordi, on trouve une autre solution, parce que c'est barbare, quand même, le cas technique. Donc ça, c'était ma première rencontre, vraiment, avec la DSN.

• Speaker #2

  Ok, très intéressant. Et sinon, pour aller sur quelque chose de plus précis, ton premier souvenir sur une anomalie, une règle ?

• Speaker #0

  Alors mon premier souvenir le plus marquant, c'est la première DSN qu'on a générée. Et on avait généré ça sur une société de tests qu'on avait créée avec deux salariés tests. Alors une DSN de deux salariés, elle devrait ressortir sans erreur assez facile, surtout qu'on l'avait travaillée avant. Bon, elle est sortie avec 80 anomalies sur deux salariés. Donc ça, c'est mon premier souvenir marquant. Et c'est normal, on partait de zéro. Donc c'est normal. Et donc de 80 anomalies, on les a analysées, on a regardé. le contexte, le problème, on a corrigé la cause, on a régénéré plus que 20 anomalies, plus 10, plus 5, plus 0, et voilà comment on a travaillé sur ce moteur de DSN qui sort une DSN maintenant qui est fiable, mais ça, c'était marquant. Cette première DSN, quand on appuie sur le bouton, on fait passer l'outil de contrôle, on croise les doigts, on ne sait pas à quelle sauce on va être mangé, et qu'on sort avec 80 anomalies partout sa clignotaire, on se dit bon, il y a encore du boulot.

• Speaker #1

  Et avec le recul, ton ressenti sur la DSN en tant que norme, tu la trouves finalement... Bien pensé, trop complexe, perfectible. On peut être honnête.

• Speaker #0

  C'est trop complexe, oui, pour l'utilisateur, parce qu'on ne lui met aucune pédagogie pour comprendre la DSN. Et en fait, il faut quand même se dire qu'un gestionnaire de paye, personne n'est en cabinet comptable, par exemple, gestionnaire de DSN. Ce sont des gestionnaires de paye. Ils connaissent la paye, ils sont experts sur leur portefeuille, ils n'ont aucune connaissance de ce que c'est que la DSN. Alors que, je le rappelle, c'est quand même là-dessus qu'on se fait redresser. Et on le voit en ce moment avec les DSN de substitution. Mais il faut aussi se rappeler de là où on était il y a quelques années, avant la DSN, et du progrès qu'il y a eu entre-temps. Tout était quand même assez manuel. Alors, il y avait la DADS, mais tout était quand même assez manuel. Et aussi de pourquoi la DSN existe. Et si on déplace le point de vue de l'éditeur ou du gestionnaire de paye au point de vue du salarié à la fin, la DSN, elle le sécurise quand même pas mal dans sa vie, sur ses droits, entre autres. Et si on regarde maintenant aussi ça avec un regard un peu plus haut, la DSN, elle permet aussi de sécuriser, d'éviter aussi un peu la fraude. Donc, elle amène quand même beaucoup de progrès. Elle est trop complexe. Il faut essayer de la décomplexifier, on va dire. Et ça, ça va passer par de la pédagogie. Et ça doit reposer, à mes yeux, beaucoup sur l'éditeur, pas sur le gestionnaire. Ce n'est pas à lui de faire l'effort.

• Speaker #2

  Merci beaucoup pour cette réponse. Et donc, on arrive à notre petite... question rituelle des aventuriers de la DSN. Est-ce que la DSN a changé ta vie ?

• Speaker #0

  Ah oui ! Oui, oui, elle a changé ma vie. Quand on a commencé Linc, on a été très axé paye. Moi, je connaissais la paye. Faire de la paye, je sais. Je sais comment fonctionne un bulletin. Je connais tous les mécanismes de la paye. Je connaissais beaucoup moins la DSN. Donc, ça a changé ma vie. Ça a changé mon approche de ce que doit être un logiciel de paye. Et un logiciel de paye doit être pensé, maintenant, avec la DSN. Donc, ça a considérablement changé même quand Merci. L'approche qu'on avait dès le départ de la paie, on l'a fait évoluer avec le regard qu'on a mis dans la DSN.

• Speaker #1

  Merci Thomas. On arrive à la fin et on aimerait que tu nous laisses quelque chose de concret. Les gens qui nous écoutent, ce sont les gestionnaires de paye, tu l'as dit, les responsables paye, les éditeurs aussi. Concrètement, qu'est-ce que toi, Linc, vous pouvez apporter à quelqu'un qui galère avec ces anomalies DSM au quotidien ?

• Speaker #0

  Déjà, je pense que le meilleur réflexe, c'est de ne pas attendre ou d'espérer que la DSM ne va pas être rejetée. Donc, y aller à l'aveugle, c'est quand même une mauvaise pratique. Oui, mais on en rigole, mais sauf que... dans les faits c'est ce qui se passe beaucoup on en voit puis on attend on est d'accord et parfois ça passe mais on le voit aujourd'hui ça passe mais un an après on vient vers nous en disant c'est peut-être passé mais finalement ça va pas donc le meilleur réflexe c'est pas ça et c'est d'essayer de comprendre l'anomalie et parfois comprendre quelque chose qui est incompréhensible c'est compliqué donc moi ce que je dirais aux gestionnaires c'est que si vous le comprenez pas le problème c'est pas vous le problème c'est le message qu'on vous envoie qui est incompréhensible et du coup la troisième chose c'est Merci. Formez-vous le plus possible, entourez-vous aussi et aussi soyez exigeant et soyez exigeant envers l'éditeur que vous utilisez pour que lui fasse l'effort de vous expliquer ce qui ne va pas.

• Speaker #2

  Très bien. Et si tu devais donner un conseil, un seul, sur la DSN ou sur la façon d'aborder la norme, à qui s'adresserait ce conseil et ce serait quoi ?

• Speaker #0

  Ça rejoint quand même ma réponse d'avant. Ce conseil s'adresse aux gestionnaires. Prenez du recul sur la DSN. tout en ayant conscience de, j'allais dire, de l'importance. C'est même au-delà de ça, de la nécessité d'avoir une DSN qui soit 100% juste. Et pas que sur les contrôles de forme, même sur le fond. Donc regardez aussi le fond de vos DSN. Et pour comprendre le fond, formez-vous, regardez ce qui est attendu dans les éléments, comprenez comment sont faits les contrôles, parce que les contrôles sont faits par des reconstitutions dans des DSN. Comprenez ces mécanismes, n'essayez pas de parler en... S21G00 ou en CCH12, mais comprenez la logique qu'il y a derrière, parce que ça, ça va vous faire comprendre comment vous allez faire votre paye et surtout accompagner soit vos clients, parce que vous êtes directement avec vos clients, ou vos salariés, parce que vous faites des payes en direct.

• Speaker #1

  Merci, merci beaucoup. J'espère que d'autres éditeurs t'écoutent et prendront le même chemin de se dire qu'il faut un peu démystifier tout ça et rendre la norme accessible. Denis peut-être veux-tu rajouter quelque chose ?

• Speaker #2

  Bon on arrive à la fin j'étais vraiment ravi de rencontrer Thomas c'était notre premier échange on n'a pas beaucoup on peut le dire pour l'instant on ne se connaissait pas on se découvre entre passionnés de la DSN et je trouve ça très très intéressant et

• Speaker #0

  bien c'est partagé, merci Amandine merci Denis, c'était un vrai plaisir de passer ce moment avec vous, j'espère que j'ai été clair et j'espère que ça parlera à tous ceux qui nous écoutent pour moi tu as été

• Speaker #1

  très clair. Mais effectivement, c'est la fin de cet épisode 2 des Aventuriers de la DSN. Vraiment un grand merci Thomas pour ta générosité, pour nous avoir ouvert un petit peu quand même les coulisses d'un logiciel de paye. Et c'est vrai que ce côté éditeur reste pour nous un sujet absolument passionnant.

• Speaker #2

  Si cet épisode vous a parlé, n'hésitez pas à le partager à un collègue, à votre éditeur, à votre DSI, à votre responsable SI, paye, etc. N'hésitez pas.

• Speaker #1

  Notre prochain épisode arrive très vite. On va continuer à explorer l'ADSN sous tous ses angles, avec un invité terrain, un sujet technique. Vraiment, ce sera notre modèle.

• Speaker #2

  Et en attendant, si vous avez un sujet que vous souhaitez qu'on traite, directement dans le podcast, une question, une anomalie qui vous hante depuis des mois, écrivez-nous, on lit tout.

• Speaker #1

  À très vite. Vous restez curieux ? Un mot pour conclure, Thomas ?

• Speaker #0

  Soyez curieux de la DSN ?