Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Heu je crois justement que son message allait dans ton sens. Il est presque impossible de reprendre des vieux trucs qui ont évolués sans avoir un minimum d'accès à la doc. Seule les techno morte et qui ne bougent plus depuis 20 ans peuvent être maitrisées par coeur, pour le reste le tableau blanc est de la blague.Envoyé par bihetq
Il y avait déjà un sujet sur ce genre de recrutement. C'est bien si c'est bien maitrisé: a savoir donner un temps au candidat ET le rémunérer pour ce temps. Sinon tu va passer en tant que recruteur à coté de candidats compétent qui ne peuvent se permettre de consacrer 10 à 20h à un seul recrutement. Quand tu cherche du boulot parce que t'as plus le tiens, entre perdre 10h à bosser sur un projet demo, ou passer 5 interview, mon choix est vite fait, je maximise mes chances d'avoir une offre.Pour ma part j'ai vécu un recrutement de rêve il y a qqs années: les mecs m'ont donné une clef USB avec tout l'environment de dev + la doc dessus et m'ont dit: vas-y, tu prends une semaine pour développer un truc, ce que tu veux, et tu nous le présente.
Bilan: cela va faire 10 ans que je travaille avec eux. D'abord en tant que salarié, et depuis quelques années comme un de leur prestataire. Que du bonheur!
Le projet demo gratuit ne va te permettre que de viser deux types de candidats à mon avis:
- Celui qui a déjà un boulot, n'as pas de contraintes familiales, et veut juste viser ta boite
- L'étudiant qui a le temps entre son TFE fini à l'avance et la remise des diplômes.
En l'occurence, ici, tu as été engagé. Quel aurait été ton ressentit par rapport au processus de recrutement si après tout cet investissement on t'aurais laché "désolé, on a pris quelqu'un d'autre qui a fait un super projet sur lequel il a passé 50h" ?
Je pensais peut être naïvement que tout le monde allait chercher ses "snippets" sur le net pour les adapter dans son propre code mais puisque que cela fait un sujet pourquoi pas approfondir. Les recruteurs sont effectivement à côté de la plaque car ils ne posent pas les bonne questions et n'évaluent en aucun cas les qualités requises pour le développement. Les compétences techniques sont déjà obsolètes une fois que l'on arrive sur le marché du travail donc ce n'est pas la dessus q'u'il faut évaluer les candidats. Je vois bien des candidats dans 10 ans devant un recruteur, "moi j'ai fait 10 ans d'Angular", la belle jambe les frameworks ont tous ont changé depuis ... Ce que je regrette c'est qu'on ne cherche pas à savoir si le candidat sera capable de travailler au sein d'une équipe et pas de bosser en mode hermite, de communiquer ses idées même après d'un public non technique (chef de projet), de former d'autres collègue, d’élaborer des spécifications techniques pour les soumettre à un architecte, de penser plus large que son domaine de prédilection pour trouver des solutions cadrant avec l'environnement et le besoin du client et surtout s'il sera capable de se remettre en question d'apprendre de nouvelles technos sur le tas ...
Ah bon ?
Du coup, pour quoi faire ? Si tout devient si vite obsolète...(...) surtout s'il sera capable de se remettre en question d'apprendre de nouvelles technos sur le tas ...
Le tableau blanc oui. Mais pas pour écrire du code !
Y a pas si longtemps que ça (tout juste un an), j'ai fait les entretiens techniques pour une place (d'analyste-programmeur/dba/testeur/tout le reste) chez nous (en interne dans un chaîne de magasins de distribution).
Mon approche était la suivante : Reproduire une situation réelle de demande interne. Bien souvent, le chef d'un service vient nous voir en disant "j'ai besoin d'un soft pour faire ci et ça". Et c'est à nous de lui tirer les vers du nez pour découvrir ce qu'il veut réellement faire et ce dont il a besoin.
Conclusion, j'ai fait "un jeu de rôle" (c'est à la mode en plus ^^) avec les candidats. Ils jouaient le prestataire et moi le client.
Comme situation, j'ai pris l'exemple de gestion d'un cabinet vétérinaire car cela ne nécessite pas, selon moi, d'avoir des connaissances spécifique au métier pour identifier les besoins de bases. Surtout que de toute façon, c'était à eux de me poser les questions. Moi j'avais un peu préparé mon sujet. L'objectif en 30 min (1h max), avoir un ébauche de schéma de DB ou de diagramme de classe (au final, c'est pareil).
L'objectif n'étant bien sûr pas de déterminer si le candidat connait la syntaxe de toutes les fonctions du framework utilisé par coeur mais de déterminer s'il est capable de raisonner correctement pour extraire les informations importantes de mes réponses.
Le tableau n'intervient donc ici comme médium de communication plus pratique que si le candidat écrivait sur un papier et que je doive regarder par dessus son épaule...
Kropernic
Tout dépend pour quel type de poste on recrute et quelle facultés on souhaite mettre en évidence par ces tests. Ne pas être capable d'écrire un algorithme de tri n'est pas rédhibitoire pour un technicien. Par contre, un ingénieur R&D qui n'est pas capable de résoudre tout seul un problème aussi simple, en raisonnant un peu, n'a probablement pas les aptitudes pour attaquer des problèmes plus complexes, et a un niveau réel de technicien.
Ca ne veut pas dire que je n'embaucherais pas cette personne, qui peut avoir d'autres qualités intéressantes, mais j'éviterais de lui confier des problèmes trop complexes, pour lesquels il n'y a pas nécessairement de solution standard disponible sur Internet.
Je ne me souviens pas combien font 9*8, je ne sais pas le retrouver en réfléchissant, mais attendez, avec une connection Internet, et en travaillant en équipe, je vais
vous trouver la solution.
Par contre, qu'un responsable ayant 30 ans d'expérience ait besoin de chercher comment obtenir la longueur d'une chaine Python ne me choque pas spécialement : il s'agit ici de mémoire d'un détail technique, associé à une technologie particulière, c'est une petite lacune facile à combler, contrairement aux difficultés à raisonner.
Combien d'entretiens j'ai annulé de peur à cause de ça... Je trouve cette façon de tester tellement stupide ... En tous cas, merci à ces gens de conforter mon avis sur la question
Alors d'abord pour résoudre un problème avancé, je préfère le gars qui va d'abord fouiller la littérature pour savoir si une solution existe à son problème qui est robuste et à déjà été testée ailleurs. Pour prendre un exemple, je pense pouvoir dire que pour mon travail de fin d'étude, j'en ai chié pour inventer des techniques innovantes pour résoudre le problème. Et pourtant j'ai bien passé 60% de mon temps à me documenter sur des algorithmes éprouvé et des mathématique dont je n'ai plus jamais eu à utiliser par la suite. Je devrais faire ça aujourd'hui devant un tableau blanc, j'en serais incapable car certaines briques fondamentales font appel à des formules mathématiques dont je ne me souviens plus exactement, et dont l'exactitude est importante pour garantir le reste de l'algo puisqu'il se base sur des propriétés démontrées de ces formules.
La première fois où on m'a demandé d'implémenter un quicksort, je me suis basé sur la description de l'algo plutot que sa connaissance, et j'ai fait travailler mes méninges. Résultat, mon algo était performant, mais c'était pas un quicksort. C'était un heapsort au final, je ne l'ai su que plus tard. Au tableau blanc, j'aurais échoué, c'était pas un quicksort.
Ensuite, pour le tableau blanc, on demande pas du pseudo code pour ce que j'ai compris, mais de pondre un bout de code de a à z sans doc. Quand je réponds aux questions sur ce forum sur comment faire x ou y, je n'utilise pas de compilateur, juste la box code de developpez. Et, "surprise", j'ai toujours besoin à chaque fois de charger la javadoc dans un onglet parce que rien à faire, je ne connait pas par coeur toutes les méthodes et l'ordre de leur paramètres en java. Je sais où elles sont, je sais ce qu'elles font, dans quelles contraintes, mais je laisse à l'IDE le boulot de gérer la forme. Au tableau blanc, je serais un homme mort.
Enfin, une fois dans ma vie, j'ai du écrire un bout de code en C sur un tableau, avec un feutre. Après trois lignes, mon prof de l'époque fronçait les sourcils. J'ai fait trois pas en arrière, j'ai vu le n'importe quoi. Entre la manière dont je réfléchissait, le temps pour écrire proprement et le fait de ne pas voir plus 10 lettres à la fois, ça partait en couille. J'ai demandé à pouvoir l'écrire au stylo sur du papier plutôt qu'au tableau. Le tableau était blanc.
Bref, j'échouerais lamentablement sur un tableau blanc. Et pourtant je suis bon en analyse, en architecture et en technique. Mais je suis à chier en gestion de projet et je pense avoir une phobie des tableaux blancs... Au moins, pour le premier point, je suis sûr que ça peut se travailler.
Je ne vois pas non plus l'intérêt d'écrire du code C détaillé au tableau.
Et ma remarque faisait référence à un des exemple donné dans l'article, cette personne incapable d'écrire un tri à bulle, même pas un quicksort. Je n'ai pas l'impression que ce soit un problème particulièrement avancé.
On s'attend normalement à ce qu'un développeur sache :
- que cette méthode est inefficace, et rarement utilisée
- mais qu'il soit quand même capable de l'écrire en 10 mn sans faire des heures de recherches bibliographiques, pour trier une douzaine de valeurs dans un environnement/langage sans fonction de tri
Après, si on a besoin de quelque chose de plus élaboré, pour trier beaucoup de valeurs, évidemment qu'on va chercher du code ailleurs.
Il y a quelques années, je posais le problème suivant : écrire une librairie de calcul en précision arbitraire sur des entiers, implémentant les 4 opérations de base, en mettant à disposition de la personne un ordinateur, du papier, un tableau, et 2h pour travailler tranquillement, sans être dérangé, tout seul dans une salle.
Le but n'était pas de tester la capacité de la personne à travailler en équipe, ni de vérifier que c'est un virtuose de google, mais d'évaluer sa méthode de travail autonome et capacités de raisonnement, sur un problème de nécessitant pas plus de connaissances en mathématiques que ce que connait un élève de CM2.
Il y a plus de 20 ans, je ne faisais pas passer de tests, juste entretien d'embauche, en comptant sur la période d'essai, j'y suis venu après avoir embauché quelques candidats pas incompétents de façon évidente, mais peu efficaces au travail.
Et encore une fois, tout dépend pour quel type de poste on recrute, et ce qu'on cherche à vérifier, je ne prétend pas que les tests techniques soient la panacée pour sélectionner des candidats dans toute situation.
Hmmm, ce n'est pas un défaut des recruteurs mais plutôt un problème de vérification des connaissances.
Beaucoup voir énormément de candidats bidonnent leurs CV. D'un langage qu'ils connaissent à peine, ils vont se prétendre "Expert", se rajouter des expériences professionnelles, s'approprié des programmes qu'ils n'ont pas écrit. Face à ça, le recruteur ne peut pas vérifier chaque cas surtout si le CV ne donne pas assez de références externes. Le seul moyen est de mettre le candidat dans une situation extrême et de juger non pas forcement le résultat mais la méthode et l'attitude.
Aujourd'hui, même dans les écoles, on n'apprend que très peu de choses comparé à une dizaine d'années. Les notions d'algorithmiques sont mises de coté pour se concentrer sur des choses plus futiles mais plus "vendeuses". Le programmeur qui ne sait pas retrouver l'algo d'un bubble-sort ne devrait même pas se prétendre informaticien. Je suis incapable de le faire de mémoire mais je sais comment retrouver cet algo et c'est bien là l'essentiel. J'aurai réinventé la roue lors de l'entretien (ce qui n'arriverait pas en situation réelle sur un poste) mais j'aurai démontré que j'ai une méthodologie pour avancer et appréhender le problème et trouver une solution.
Le dinosaure se marre !
Ce type d'entretien est normalement la marque d'une grande incompétence de la part de ceux qui le font passer. Il revient à un QCM : Pas besoin de réfléchir au contenu, pourvu que les bonnes cases soient cochées.
Cette manière de faire est en contradiction totale avec ce qui m'a amené à l'informatique (analyse, conception, programmation, installation, maintenance, sans parler de la partie matérielle ni du réseau...) il y a fort, fort longtemps. Et c'est bien dommage. Depuis des décennies "on" essaie d'industrialiser le processus de création d'applications. Mais la contradiction est inhérente à l'expression : Une application est "créée", elle n'est pas usinée. Ou si on l'usine, on obtiendra un produit industriel, adapté au plus grand nombre pour 80% de ses fonctions. Ca peut suffire pour une comptabilité, qui est la même en gros pour tout le monde. Mais ensuite, industrialiser des applications métier ne fait aucun sens et aboutit au contraire à stériliser un domaine.
Bref ! Je préfère infiniment quelqu'un capable d'expliquer ses choix de développement, de me montrer ce qu'il utilise et comment il l'utilise pour écrire son code, comment il organise son poste de travail, à quel rythme il avance et d'où il tire ses ressources de référence qu'un petit robot bien calibré capable de me dégoiser le Knuth par coeur. Vous ne savez pas ce qu'est le Knuth ? Tant mieux !
Vous voulez vraiment tester ce que quelqu'un peut faire ? Donnez-lui un bout d'application à maintenir, un truc qu'il n'aura pas encore vu. Et voyez comment il s'y prend et comment il évolue. En quatre heures, vous saurez si oui ou non, et ce sera de la vraie connaissance.
Quant au péché... J'ai dû produire pas mal de code COBOL, partie en maintenance, partie de neuf. J'ai dû écrire pas loin d'un million de lignes, plutôt plus (si, si, je vous jure, ça va vite et j'ai duré longtemps). Je suis toujours incapable de démarrer un programme COBOL de rien, j'ai absolument besoin d'un patron syntaxique. Et ça ne m'a jamais, mais alors jamais posé le moindre problème !
Donc, vu d'un oeil de dinosaure, ne vous cassez pas la tête avec le tableau blanc. Si quelqu'un vous y colle, tournez les talons, vous trouverez sans doute une boîte plus intéressante pas loin dans le coin.
Bonjour
Je n'ai jamais eu à faire ce genre de tests mais j'en suis curieux.
Si j'ai bien compris, on demande au candidat de développer quelque chose ou résoudre des problèmes "à la main levée" sans autre ressource que ce dont il se souvient.
C'est bien ça ?
Je trouve que c'est un exercice intéressant dans la mesure où cela oblige à faire avec ce que l'on a en tête, ça permet de prendre confiance.
Quant à en faire un examen au cours d'un entretien d'embauche ... j'avais déjà entendu parler de cette pratique, c'était pour le concours de l'Ecole Normale Supérieure.
Lors de l'épreuve orale pour cette école, un candidat s'était retrouvé en face d'un tableau presque vide avec juste un circuit électrique dessiné dessus, très simple en apparence,
avec l'injonction de dire tout ce qu'il savait dessus.
Je fais du travail de développement depuis plusieurs années dans le monde scientifique en C++/fortran/python/swig/Ocaml/lua, je code très rarement à partir de rien et m'inspire
souvent de bout de codes trouvés sur internet. Je crois que si je passais ce genre d'entretien, je passerais pour un gros imposteur, j'aurais même je pense quelques difficultés
à expliquer les notions et algorithmes que je récupère car bien souvent, je ne cherche pas à tout comprendre, le plus important est d'en bien saisir les entrées et sorties.
Si je devais faire passer des entretiens d'embauche, je chercherais à m'assurer que la personne est rapidement capable de retrouver ce qu'il lui faut dans de la doc ou sur internet,
l'essentiel étant de ne pas s'enliser dans la pagaille de toutes les solutions possibles. Je regarderais aussi ses précédentes réalisations. Je garderais le type d'entretien "tableau blanc"
comme un exercice pour éviter de devenir trop dépendant de la documentation.
Jarodd
quoi de plus a ajouter drrrrrr tu as raison
Si un recruteur demande à un candidat d'écrire un algorithme de tri simple de son choix, sans forcément savoir comment s'appelle cet algorithme, mais que ce dernier n'y parvient pas, alors je comprends que le recruteur craint que le candidat ait un niveau algorithmique trop faible pour travailler dans sa boîte.
Par contre, si un recruteur demande à un candidat de coder un tri à bulles mais que ce dernier ne se rappelle plus à quel algorithme cela correspond, je pense que ce serait injuste de pénaliser le candidat. Après tout, le tri à bulles n'est pas le seul algorithme de tri trivial à complexité quadratique. Il y a aussi le tri par insertion et le tri par sélection. A quoi bon se rappeler lequel correspond à quoi alors que, dans 99,99% des cas, on va seulement appeler une fonction standard qui fait un tri avec une complexité en O(n log n) ?
Heu... es-tu sûr que c'était un heapsort ? Je vois mal comment on peut se retrouver à implémenter un heapsort à partir d'une description, même vague, du quicksort.
Description simplifiée du tri rapide (quicksort) : On choisit un élément comme pivot. Puis on s'arrange pour que tous les éléments à gauche du pivot soient inférieurs ou égaux au pivot et que tous les éléments à droite du pivot soient supérieurs ou égaux au pivot. Le pivot coupe alors le tableau en deux sous-tableaux. On applique l'opération de manière récursive à chacun de ces sous-tableaux.
Description simplifiée du tri par tas (heapsort) : On voit le tableau comme un arbre binaire. Le premier élément est le sommet, les 2 suivants sont les enfants du sommet, les 4 suivants sont les petits-enfants et ainsi de suite. On s'arrange pour que chaque nœud soit plus grand que chacun de ses enfants. Ensuite, on échange le sommet (qui est forcément le plus grand élément) et le dernier élément du tableau. On ignore le dernier élément du tableau (la taille du tableau diminue alors de 1) et on recommence récursivement l'opération.
Cela va de soi
Comme disent les ricains, c'est un NO BRAINER, autrement dit ce n'est même pas une question. Je n'ai que 40 ans d'expérience en programmation et Depuis que l'informatique existe, les bons programmeurs ont toujours fait de la réutilisation. Pourquoi ? : parce qu'on est plus productif, parce que c'est un moyen d'apprendre, parce que c'est un moyen de trouver de nouvelles idées, parce que réinventer la roue peut parfois donner l'impression d'être génial ou créatif mais... En fait c'est comme dans le monde universitaire, qui prétendrait réinventer les maths en partant de zéro ? Au contraire c'est en ça s'appuyant sur le savoir des anciens et en sachant repérer et reprendre ce qu'ils ont fait de mieux et de plus intelligent que l'on prouve sa propre intelligence et que l'on passe au stade supérieur. Et aujourd'hui internet nous la merveilleuse facilité de ne pas avoir que les livres à fouiller pour trouver le savoir.
NO BRAINER
Vu de l'oeil d'un autre dinosaure, qui a dû coder plus de 7 millions de lignes dans une quinzaine de langages sur 5 plateformes différentes sans jamais avoir eu un cours d'informatique, je suis tout à fait d'accord avec mes 2 collègues plus haut..
Je trouve que ce genre de choses est absurde.... Même de savoir la différence entre un tri à bulle et le reste....
Tu cherches "tri" sur ton système d'exploitation et tu auras "qsort". OK. testé et optimisé. Basta...
Quant à mon péché....dans une application critique de plus de 700 000 lignes dont j'étais et le CP et le principal codeur, en particulier de l'IHM, tous mes fichiers faisaient plus de 5000 lignes, quelques uns plus de 10 000, et j'ai fait 2 fonctions de plus de 3000 lignes.... Yep....
Une immense boucle de contrôle de l'affichage, qui pouvait fonctionner temps réel ou non, être repassée dedans pendant une utilisation normale pour générer un film, et où tous les paramètres pouvaient être changés dynamiquement en même temps que la boucle tournait... avec des données et des tableaux de données se créant en cours de boucle... Trrrrooooooppppp compliqué de tout découper, avec en plus des overheads prévisibles plus que non négligeables (appeller 20 fonctions avec (même par pointeurs), une vingtaine de paramètres, ... et surtout tenir compte dynamiquement des changements ailleurs)..
Oui je l'avoue
Et je ne connais ni le nom ni le détail d'aucun algo de base, sauf éventuellement une moyenne glissante, et les moindres carrés.....
C'est d'ailleurs une des raisons pour lesquelles je ne retrouve pas de boulot et ai abandonné l'idée d'en retrouver... On ne croit plus aux "têtes bien faites" mais aux "têtes bien pleines"....
J'échouerais lamentablement à ce type de test, et je n'ai pas envie de me taper d'apprendre des trucs si les gens qui m'embauchent ne sont pas capables de lire et comprendre mon CV..
PS: ce code a quand même tourné 16 ans opérationnellement dans un environnement 24/24 7/7 dans un grand service gouvernemental de sécurité publique dit "service essentiel" ...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Oui, on a parfois besoin de faire des monstres. Pas souvent, mais parfois.
En bancaire, j'ai été backup sur la maintenance d'un monstre de 36,000 lignes, quand son auteur était en vacances. On m'a demandé si on pouvait le découper pour le rendre plus digeste. J'ai passé une semaine dessus, et ma conclusion a été : "vous pouvez gagner 6/7 miile lignes en factorisant les gestions d'erreurs. Le reste, vous pouvez vous gratter, si vous découpez, ça sera encore pire".
Parceque tout était dépendant de tout(la spécification le voulait, et elle dépendait essentiellement du réglementaire, donc non négociable). Tout ce qui était déjà exportable(à part la gestion d'erreurs, vraiment optimisable) avait déjà été exporté. Les urbanistes ont hurlé que j'étais incompétent, et je leur ai montré mes autres réalisations : des trucs standards, avec plein de petites fonctions, bien découpées, et tout. Mais c'étaient des cas ou c'était possible. Pour ce cas précis, non.
J'ai plus tard moi-même commis un monstre de 2000 lignes(certes, c'est moins impressionnant) d'un bloc, avec des boucles imbriquées partout, alors que ce n'est pas du tout mon style. Mais, là non plus, je n'avais pas le choix. Dans ce cas spécifique, les limitations du COBOL (qui en 8 ans ne m'avais jamais trahi) m'ont empêché de faire un truc propre. Comme le dit Souviron34, les deux codes tournent comme du papier à musique. C'est certes peu satisfaisant intellectuellement, mais l'important, à la fin, c'est que ça tourne, et qu'en plus on arrive à peu près à le maintenir. Ce qui était le cas.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
encore une fois je vais le réecrire maitriser et utiliser des technos ça ne sert strictement à rien si le projet est mal construit, mal conceptualisé...et même si on utilise les dernières technos distribuées sur le marché
Une "techno" n'est pas une finalité c'est un moyen contrairement à ce que les gens du marketing veulent nous faire croire..
c'est comme si on m'offrait une licence d'Unity 3d le middleware qui permet de créer des jeux vidéos sans trop de code , bon c'est bien d'avoir une licence de cet outil mais si j'ai pas un concept de jeu vidéo valable et valide , cet outil me servira à rien..
ça c'est le gros problème de notre société consumérisme et conditionnée par les codes du marketing c'est comme la mode ou les produits de beauté..
une entreprise va développer un projet avec une techno A , le marketing nous dit "bon eh bien vous pouvez jeter votre projet il est devenu obsolète" comme ça les éditeurs de matériel et de logiciels gagnent de l'argent avec les royalties le cas échéant.
Ensuite pour ce qui est de l'obsolescence des technos , un projet qui est bien conceptualisé un max et bien d'équerre, l'évolution technologique c'est pas un problème (quoique dans la pratique c'est souvent différent et ça entraine pas mal de travail supplémentaire )
Si on conçoit une classe générique clients en Java ou en NET bref on fait abstraction au maximum des technos en principe c'est pas un problème pour porter ces classes avec des nouvelles technos
je conçois une classe pour les clients qui peut être héritée le cas échéant ça peut être largement réutilisé et pas besoin de réecrire du code
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10public class Client { private: string nom; string prenom; string Raison_sociale; puiblic: void AfficheClient{}; }
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager