Bug avec la fonction CONCATENER

j'utilise la fonction CONCATENER sur une plage de cellules.

ces cellules contiennent toutes des dates formatées en date (option français et calendrier grégorien)

donc la résultante est une date.

Or cette résultante apparait IRREMEDIABLEMENT sous format standard (donc par exemple pour le 11 juin 1921 il s'affiche le nombre 42896) !!!

il apparait donc impossible de faire afficher le résultat sous format date (11-juin-21)

Est-ce une particularité de la fonction CONCATENER??

je précise que dans cette même cellule où s'affiche mon résultat, si j'entre la même date : elle s'ffiche bien en format DATE (11-juin-21)

Merci de vos réponses

Bonjour,

Tu peux mettre 1 exemple de fichier?

Je vois pas trop ce que tu compte faire à concaténer des dates.

Bonne journée

bonjour,

essayez :

=texte(concatener(vos valeurs);"jj/mm/aa")

ou le format texte qui vous convient

et en mettant la cellule résultat au bon format (format date au lieu du format standard ?)

Bonjour

astragor a écrit :

et en mettant la cellule résultat au bon format (format date au lieu du format standard ?)

Non toute concaténation, quelle soit faite par CONCATENER ou & ou autre, ne tient pas compte du format.

Il faut donc utiliser TEXTE comme suggéré par njhub, exemple

=A5&" "&TEXTE(B5;"jj/mm/aaaa")&" "&TEXTE(C5;"# ##0,00 €")

bonjour à tous

à quoi peut bien servir de concaténer du texte et une date

bonjour,

jmd a écrit :

bonjour à tous

à quoi peut bien servir de concaténer du texte et une date

a résoudre le pb d'affichage du numéro du jour, après opérations sur les dates,

pour afficher non pas le n° du jour mais bien la date,

ce qui est le résultat attendu dans la demande initiale

njhub a écrit :

bonjour,

jmd a écrit :

bonjour à tous

à quoi peut bien servir de concaténer du texte et une date

a résoudre le pb d'affichage du numéro du jour, après opérations sur les dates,

pour afficher non pas le n° du jour mais bien la date,

ce qui est le résultat attendu dans la demande initiale

pour afficher une date (qu'elle soit calculée ou saisie au clavier ) il suffit mettre la cellule au format voulu. Pas besoin de concaténer.

En fait j'explique mon problème à résoudre :

je dois aller chercher, dans un fichier à plusieurs feuilles formatées de manière identique, une case avec une date à l'aide de RECHERCHEV.

Mais si la recherche échoue, je ne veux pas N/A mais ""

Il y a douze onglets, donc avec la fonction SI ça fait imbriquer une formule énorme...

à moins qu'il y ait une autre solution?

Celle que j'ai trouvée avec mes petits moyens, c'est CONCATENER :

j'ai utilisé deux astuces trouvées à tâtons :

1-- pour avoir un chiffre en cas de RECHERCHEV infructueuse, j'ai ajouté l'argument "1" dans CONCATENER, et j'ai ensuite ajouté "-1" au total pour respecter la condition du SI (>0)

2-- pour résoudre le problème de format, j'ai simplement ajouté +0 à la fin dans la condition VRAI

Voici ma formule complète pour les experts qui pourraient peut-être me simplifier tout ça :

=

SI(

CONCATENER(

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX));"1")-1;

(

CONCATENER(

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));

SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX))) +0

);"")

Merci à tous

beuhhhh (pleurs)

on voulait un fichier

Effectivement une formule de 3550 caractères mérite d'être simplifiée.

Vous faites votre recherche dans un second fichier, [LESUEUR FCPI ANGLES V7.xlsm]

pourquoi ne pas la faire directement dans le fichier concerné?

En rajoutant une feuille "Rechhe" qui reprendrait en A1 l'information que vous entrez en AA12

et à la ligne 1002 en colonne Q de chacun des onglets :

=SI(ESTERREUR(RECHERCHEV(Rechhe.A1;$P$4:$Q$1001);2;0);"";RECHERCHEV(Rechhe.A1;$P$4:$Q$1001);2;0))

Puis pour rappatrier ces données dans l'onglet "Rechhe"

en B2 :

=Lesueur.Q1002

en C2 :

=MandatsSignes.Q1002

en D2 :

=CompromisFCPIANGLES.Q1002

en E2 :

=MandatsRetires.Q1002

en F2 :

=VendusFCPIANGLES.Q1002

en G2 :

=PasDeRetour.Q1002

en H2 :

=Vendus.Q1002

en I2 :

=PasInteret.Q1002

en J2 :

=contactsFCPI.Q1002

en K2 :

=PasDeNums.Q1002

En B3 :

=concatener(B2;"-";C2;"-";D2;"-";E2;"-";F2;"-";G2;"-";H2;"-";I2;"-";J2;"-";K2)

Finalement en remplacement de votre formule initiale

=('[LESUEUR FCPI ANGLES V7.xlsm]Rechhe'!B3)

Re

jmd a écrit :

bonjour à tous

à quoi peut bien servir de concaténer du texte et une date

Il m'est arrivé de l'utiliser pour fabriquer des mentions à partir de plusieurs cellules, souvent pour du publipostage...

Mais ici effectivement ce n'est pas le souci...

ok merci de prendre du temps pour problème. c'est vraiment sympa;

1/ le problème c'est que cette formule est copiée dans tout un tableau, incrémentée donc AA12 puis AA13 etc...

2/ il me semble que l'on pourrait mettre la formule n'importe où pas forcément dans Q2 de chaque onglet?

d'autre par le fichier LESUEUR FCPI est partagé sur Dropbox avec un client et je ne veux pas qu'il soit géné par ces calculs qui ne le concernent pas. à moins aussi de vérrouiller les cellules concernées....

Bonjour à tous !

Je profite d'un moment libre pour livrer sur ce sujet, non une solution (car je n'ai pas encore compris la teneur exacte de la question ), mais mes réflexions "philosophiques" à son propos (qu'on ne me demande nullement, ce qui n'est absolument pas une raison pour m'empêcher de les exposer ! )...

D'abord il me semble que c'est typiquement un sujet où l'absence de fichier illustrant clairement le résultat à atteindre produit une discussion partant en tous sens dont le résultat a de fortes probabilités de ne pas être particulièrement positif (il me semble aussi que je rejoins l'avis implicite de jmd sur ce point).

Je suis toujours effaré quand je vois une formule qui dépasse 3 lignes ! En pareil cas j'abandonne la formule ! Et même avant si je peux penser qu'elle va dépasser 3 lignes ! Et je trouve que c'est l'attitude la plus sage... Dans un tel cas VBA s'avèrera toujours plus pratique qu'une formule...

CONCATENER : je considère que c'est le prototype de fonctions complètement inutiles que peut parfois produire Microsoft. Elle n'ajoute en effet strictement rien à ce que l'on peut faire avec l'opérateur & et son utilité est de ce fait pratiquement nulle.

Alors qu'un =CONCATENER(A1:A12;" - ") qui produirait la concaténation des valeurs de la plage en les séparant par des tirets entourés d'espaces (ou tout autre séparateur que l'on passerait à la fonction) serait d'une grande utilité, force est de constater qu'Excel ne dispose que de peu de fonctions pour manipuler des chaînes et que l'on n'y parvient en les utilisant qu'au prix de formules complexes !

En regard, VBA offre en contrepartie nettement plus de possibilité en la matière, et d'un maniement considérablement plus aisé... A tel point que bâtir une fonction personnalisée en VBA est le plus souvent plus simple à concevoir et plus rapide à réaliser que contruire une formule avec des fonctions classiques pour tenter d'aboutir au même résultat.

Cordialement .

re à tous

je suis d'accord avec MFerrand concernant la nécessité de joindre un fichier pour toute question sur le forum

https://forum.excel-pratique.com/forum-excel-pratique/2-suggestions-t68316.html suggestion n°2

je suis en complet désaccord avec lui concernant VBA

VBA est difficile à manipuler sans formation solide et sans pratique régulière.

VBA augmente en complexité dès qu'on crée 2 macros qui se chevauchent. Par charité, oublions classeurs avec 5 macros, ingérables.

VBA n'est pas stable (en cas d'évolution de Windows, de Mac, de tableur (OOO) ou de plateforme comme le Cloud et tout autre système de tableurs qui concurrence Excel). Bon en même temps les TCD que j'adore ne sont pas toujours bien supportés mais c'est mieux.

avec l'évolution des formations scolaires (de mauvaise qualité, MFerrand tu confirmes ? ) on va bientôt voir des gens qui ont "appris" VBA mais ne savent pas faire une addition avec = et + et qui voudront une macro pour calculer 1+1

concernant les formules à rallonge, il suffit de les éclater en 3 ou 4 cellules pour mieux les maîtriser. Je ne m'en prive pas en créant souvent 3 colonnes de pointage au lieu d'une seule pour mieux comprendre la manoeuvre.

Ainsi décomposée, une longue formule devient le plus souvent compréhensible et modifiable même avec un petit niveau Excel.

Au fait, pourquoi Microsoft cache VBA dès l'installation d'Excel ?

avec ce long discours, je ne veux fâcher personne, MFerrand tu sais bien.

amitiés excelliennes à tous.

Terrible !

avec ce long discours, je ne veux fâcher personne, MFerrand tu sais bien.

Pas de souci de ce point de vue !

Au fait, pourquoi Microsoft cache VBA dès l'installation d'Excel ?

Je suppose que lorsqu'un utilisateur d'Excel est en mesure d'accéder à l'éditeur VBA, il a acquis une connaissance d'Excel suffisante pour éviter de faire des catastrophes avec VBA, si on résume... Et si c'est le cas, Microsoft a tout à fait raison de ne pas ouvrir l'accès à VBA par défaut lors de l'installation.

Mais on ne peut pas dire que ce soit vraiment caché, l'accès est documenté, et l'expérience montre qu'on peut y accéder facilement sans avoir aucune idée de ce qu'on fait...

VBA est difficile à manipuler sans formation solide et sans pratique régulière.

Hélas non ! Il n'y a qu'à voir le nombre de demandeurs qui arrivent avec un bout de code trouvé à droite ou à gauche et qui veulent l'utiliser à autre chose que ce pour quoi il a été écrit...

Mais je suis bien d'accord que cela exige quelques connaissances minimales et qu'il convient de les acquérir, puis de les accroître avec l'usage. On a vu des internautes arriver sans connaissance en la matière, qui s'y sont mis et ont progressivement maîtrisé leur sujet, et même de façon assez rapide... trop peu nombreux certes, mais la démarche est possible et elle donne des résultats, comme en tout domaine.

VBA augmente en complexité dès qu'on crée 2 macros qui se chevauchent. Par charité, oublions classeurs avec 5 macros, ingérables.

Là je ne m'y retrouve pas ! Il n'y a pas plus de complexité avec 2 10 ou 100 macros qu'avec une. On sait faire ou on ne sait pas, et quand on veut faire sans savoir, ça cafouille ! Et je trouve ça bien normal ! Et même que ça cafouille pas assez à mon sens dans pas mal de cas que j'ai rencontré !

D'abord, quand on pense macro, on est déjà dans l'erreur ! On doit penser projet et recours à la programmation justifié par la nature du projet, on doit concevoir le projet et son programme d'utilisation, dans son ensemble et dans ses parties, dans le détails et avec toutes les interactions susceptibles de se produire, avant de penser à écrire la première ligne de code...

Et je dirai que pour un projet simple un programme simple se matérialisera en moyenne par une vingtaine de procédures, si on programme correctement, de façon dite modulaire, de façon à avoir des procédures qui ne font en général qu'une chose et la font bien... Il m'est arrivé de voir des macros à rallonge fourre-tout, dont on n'arrive plus à savoir ce qu'elle fait ou pas, dont le nombre de lignes de code est supérieur à celui de mes 20 procédures évoquées mises bout à bout, toujours remise en chantier pour essayer de la faire fonctionner normalement, mais telle que conçue elle ne le pourra jamais !

Je laisse de côté le cas de macros destinées à faire une opération une fois, que l'on trouve trop longue ou pénible à réaliser manuellement (surtout quand quelqu'un d'autre fait la macro ! ). Dans ce cas, qui peut s'avérer justifié, on exécute la macro, et on la jette ! Un des problèmes rencontrés vient d'ailleurs de tentatives de réadapter ce type de macros à autre chose... Pour un besoin ponctuel, si on le traite par macro, il faut savoir se débarrasser immédiatement après de ladite macro et ne surtout pas chercher de réutilisation. Pour un autre besoin, même proche, il faudra du sur-mesure ciblé sur le besoin précis...

VBA n'est pas stable (en cas d'évolution de Windows, de Mac, de tableur (OOO) ou de plateforme comme le Cloud et tout autre système de tableurs qui concurrence Excel). Bon en même temps les TCD que j'adore ne sont pas toujours bien supportés mais c'est mieux.

Là tu es un peu de mauvaise foi ! VBA est très stable, le code écrit sous VBA4 fonctionne toujours sous VBA7, et le passage aux nouvelles versions d'Excel depuis 2007 n'a pas provoqué de problème de compatibilité côté VBA, alors qu'il y en a pour Excel...

Ensuite, les problèmes entre plateformes ne sont pas nouveaux et aucune responsabilité côté VBA ! On connaît des problèmes avec Mac parce que Microsoft n'a pas fait d'effort particulier pour les résoudre et Apple n'a pas non plus fait en sorte qu'Office fonctionne parfaitement sur son système... VBA n'est pas utilisable sous Open Office, c'est fort dommage mais il faudrait changer les règles commerciales... !

En fait, nous aurions tendance à être plutôt d'accord et je trouve dommageable que tu te refuses l'utilisation d'un outil susceptible de rendre des services, ne serait-ce que dans les cas où Microsoft n'apporte pas d'autre solution. Que tu ne souhaites pas recourir à VBA est une chose mais mettre un interdit systématique en est une autre... Je n'ai pas recours aux TCD, je ne raffole guère non plus des tableaux Excel, et il se trouve que je n'ai pas besoin d'en utiliser dans mes activités propres, mais si le cas survenait et que cela m'apporte une solution plus simple, je n'hésiterais pas... !

concernant les formules à rallonge, il suffit de les éclater en 3 ou 4 cellules pour mieux les maîtriser. Je ne m'en prive pas en créant souvent 3 colonnes de pointage au lieu d'une seule pour mieux comprendre la manoeuvre.

Ainsi décomposée, une longue formule devient le plus souvent compréhensible et modifiable même avec un petit niveau Excel.

Bien sûr tu as raison sur ce point ! Du moins quand il est possible de l'éclater (et quand tu n'as pas à couvrir des milliers de lignes de formules). Il faut distinguer plusieurs cas : d'abord l'émulation sur le Forum fait que l'on recherche toujours sur un problème de formulation à y répondre en une seule formule, sorte de challenge, et c'est intéressant et de nature à faire progresser...

Ceci dit, dans mes propres fichiers je préfère souvent éclater sur des cellules relais masquées plutôt que d'utiliser une matricielle complexe qui sera plus gourmande en ressources que l'ensemble des formules simples résultant de l'éclatement. Ce qui n'empêche pas de saivoir faire les deux !

Ensuite, des formules trop longues peuvent résulter du fait que l'on veut faire faire trop de choses à une seule formule, mais aussi de la méconnaissance de certaines fonctions que l'on pourrait substituer à celles qu'on utilise et qui raccourcirait, ou de façon de formuler permettant aussi de raccourcir...

Mais dans tous les cas, le choix du recours à VBA ou non doit reposer sur d'autres critères... Il est bien évident que s'il s'agit de se tourner vers VBA parce qu'on n'est pas capable de formuler correctement, je ne bougerai pas le petit doigt pour apporter mon aide !

Mais dans les cas où VBA s'avère plus simple, plus pratique et plus efficace, on aurait tort de ne pas y recourir...

Et je dois dire que s'agissant de manipulations de chaînes, j'ai fait suffisamment de fonctions personnalisées pour pouvoir constater que c'est toujours plus simple qu'avec formules et plus rapide (temps d'écriture de la fonction inclus !) Et ce faisant j'ai le sentiment qu'on ne fait que pallier les insuffisances de Microsoft en matière de fonctions relatives aux chaînes de texte !

On peut certes dans un certain nombre de cas aller puiser dans les matricielles texte de Boisgontier, je ne m'en prive pas ! Et souhaitant toujours savoir comment faire par formules si j'y parviens, j'étudie les solutions possibles, mais au moment de la décision je me tourne en principe toujours vers le plus simple...

Et lorsqu'on a du texte brut à traiter pour en extraire un certain nombre de données, l'envisager avec des manipulations (manuelles) et des formules peut à la rigueur se concevoir si c'est une opération unique, mais selon les cas et si elle doit être répétée, le recours à VBA peut éventuellement apporter une solution...

Et je laisse de côté les cas où les formules alourdissent quelque peu un classeur... Moi qui fait en sorte de ne pas avoir de classeur qui atteigne et dépasse 1 Mo !

avec l'évolution des formations scolaires (de mauvaise qualité, MFerrand tu confirmes ? ) on va bientôt voir des gens qui ont "appris" VBA mais ne savent pas faire une addition avec = et + et qui voudront une macro pour calculer 1+1

Les macros pour faire 1+1, on a déjà vu le cas ! On voit souvent le cas aussi de macro pour aller flanquer des formules dans les cellules et qui doivent y rester ! Ça me laisse toujours rêveur car écrire une formule en VBA est plus compliqué que l'écrire dans la cellule !

Je ne sais pas si les formations scolaires sont de mauvaise qualité, je ne me prononcerai donc pas sur ce point. Il est certain que ce n'est plus ce qu'on a connu antan ! Des évolutions sont toujours nécessaires mais j'ai l'impression qu'on a un peu perdu de vue le but premier qui est d'apprendre à acquérir des connaissances (et non simplement d'acquérir des connaissances...) et qu'on pense que quelques techniques peuvent suffire et dispenser de réfléchir... (fétichisation qui se substitue à la réflexion...) J'ai quelques anecdotes, que je réserve pour une autre fois, cela nous ferait trop dériver.

Bonne journée.

Rechercher des sujets similaires à "bug fonction concatener"