Watch this episode on YouTube or find Sequence on Spotify.
Sequence is the DNA Solutions podcast. We spend our days using technology to understand how people behave; in this show we do the opposite, and try to understand the technology industry through the people who actually live in it.
The first episode is a conversation with Sydney De Clercq, project manager and frontend web developer at DNA Solutions. He has been here six years. He was, by his own count, the fourth employee. And he has no computer science degree: he studied translation and interpretation, English and Chinese, then spent five years as a tourist advisor around Brussels' Grand Place before a five-month bootcamp put him in front of a hiring manager.
The conversation is in French. The article below retells its substance in English, for readers who prefer text.
The episode in five takeaways
- A bootcamp's honest goal is employability, not mastery. Sydney gave himself five months to get back on the job market, and the market of six years ago met him halfway. He says himself that window has narrowed.
- His translation degree was not wasted time. Project management is translation work: clients and developers speak the same language but do not use the same words, and most project failures start there.
- Side projects were the real school: a university application platform, an SEO-driven site for a travel planner, even a Pokémon card sorter. Each one taught something a course never covered.
- His take on AI tools is unsentimental: an expert available at every step, fine to trust for execution speed, never for the initial architecture. And vibe-coded systems break precisely where experience would have looked.
- Six years at the same company came down to culture mechanics, not luck: retrospectives every two weeks, fixing the source of problems instead of blaming people, and planning for the 0.1% failure case.
Translation studies were no detour
Asked whether starting in translation means he lost years, Sydney pushes back. His whole career, as he tells it, is one job: making people who do not share a vocabulary understand each other. Translation does it across languages. Tourism did it across cultures, five years of answering questions in whatever language walked up to the desk. Project management does it between clients and developers, who nominally speak the same language and consistently do not mean the same things by it.
His example is concrete. On one project, the client used three distinct terms: activity, session, event. Three separate concepts in their business logic. The development team merged them into one at the start, and paid for that shortcut for the rest of the project. Sydney's definition of his job is preventing exactly that: checking, continuously, that what the team is building is what the client meant, not what the team heard.
He extends the same idea to code itself. Code, he says, is just another language, a way of laying out logic so a human can talk to a machine. Coming from languages made that framing natural.
What five months of bootcamp buys
The bootcamp was the Wild Code School, five months, intensive, built for career changers. Sydney is precise about what it was for: being employable at the end. Not knowing everything about software development. Employable. He needed to pay rent, and five months was the time he gave himself.
What it delivered, in his telling, was less a curriculum than contact with the ground. Three projects during the course, the last one for a real client, who used the resulting prototype to go raise investment. A basic tour of the whole terrain of web development, enough to know what exists and where to dig later.
His comparison with the university route is not dismissive, it is economic. A degree spends years on the history of code, the layers of abstraction, the deep foundations. All of that has value, and he says you can acquire it later, while employed. What the market was buying six years ago was people who could start. Tech was hiring juniors everywhere, AI had not arrived, digitalization was accelerating, and companies expected to finish the training in-house. DNA Solutions hired him out of the bootcamp and seniors trained him on the job.
Asked if he regrets not doing the academic version, his answer is that the bootcamp brought him exactly where he wanted to be, and that a developer is in permanent retraining anyway. The five-year degree does not exempt you from that; nothing does.
His honest warning to the 2026 candidate
The conversation does not let the story sit as a recipe, and neither does Sydney. Asked what he would tell someone attempting the same jump today, he starts with the uncomfortable part: a large share of junior positions have been conceded to AI, and the junior market is genuinely hard right now.
What survives of his path, in his view: it is still possible, self-taught or guided, and plenty of platforms and schools exist. But the differentiator is unchanged and now unforgiving. Passion, expressed as a trail of side projects. His examples are deliberately small: build something that displays your CD collection, catalogue your favorite films. Not because those projects impress anyone, but because a stack of finished small things is what proof of motivation looks like from the hiring side.
Even for motivated candidates with a GitHub full of projects it is hard at the moment, he concedes. His position is that in every saturated market, the people who keep going are the ones who end up through.
The side projects were the second school
The pattern that stands out in the conversation is how much of Sydney's actual competence came from projects nobody assigned him.
Apply Future was the biggest: a web platform centralizing university applications for foreign students, mainly toward French universities, initially for a Chinese audience. Every school asks applicants for the same pile: personal details, language test results, motivation letters. The platform made students enter it once and apply everywhere. Covid stopped the project cold. He still thinks the demand exists.
A travel organizer's website, built for his partner, taught him SEO in the only way that sticks: needing real clients to actually find the site. His summary of the lesson is about focus, deciding what genuinely adds value to the product instead of what is fun to build.
A Pokémon card arranger, never deployed, exists to sort cards by color so they look good framed. He brings it up without embarrassment, which is rather the point: the habit of building is the skill. What each project is for matters less than the fact that each one forced a new corner of the terrain.
Before any of that, there was competitive gaming. Sydney played semi-professional Overwatch as a tank and shot-caller, the player who makes the calls and manages the team's temperature between matches. He describes the job in terms any project lead will recognize: information moving fast, decisions in seconds, frustration management when execution does not match the plan, replay analysis where everyone is sure the mistake was someone else's.
He is careful with the analogy, project management rarely needs decisions within five seconds, but the core transfer is real: knowing the whole state of the project, the constraints, the objective, and keeping communication clear when it matters.
Reading what clients do not say
The middle of the episode is a compact lesson in why iterative delivery exists. Sydney walks through it from the practitioner side: the agile manifesto is 25 years old, and the method it replaced, waterfall, had clients describe everything up front and receive a delivery six months later. Delivered to spec and rarely satisfying, because between what the client imagined and what the team imagined, the words were the same and the pictures were not.
Two people reading the same book do not see the same scenes, as he puts it. Short iterations exist so the correction happens every two weeks instead of once, at the end, when it is expensive.
His best example of what listening buys: a scheduling tool for driving schools. The client's existing planning ran on a Windows program roughly thirty years old, dense information in tiny text, meaningful colors and abbreviations, and to them it was fine, because all the important information was there. The team rebuilt the view, and then delivered the thing nobody had asked for: every field customizable per activity type, so each activity could decide what information mattered on screen. The clients were delighted.
Sydney's reading is that clients are focused on one main problem and cannot be expected to specify the quality-of-life layer around it; they do not have the technical vocabulary to know what is cheap to ask for. Proposing that layer is the job.
An unsentimental view of AI
Sydney's relationship with AI tools is relaxed in a way the conversation probes directly. He uses Claude for his side projects and describes AI as an expert permanently at your side, on every subject, usable at every single step of a project, either to assist the human step or to replace it.
The boundary he draws is precise. Execution: delegate freely, if speed matters, tell the tool it has the rights and let it make the technical calls. The initial design of a system, the architecture, the founding reflection: never. Confront your own thinking with the AI's analysis afterwards, build from that exchange, but the decision belongs to the human. He cites the cautionary genre of AI agents deleting production databases because a human granted permissions without reading.
On vibe coding, shipping products by prompting without understanding, his critique is structural. Nothing is respected except the visible result, and the result works until it does not. When it breaks, and the AI cannot resolve the problem it created, the owner discovers vulnerabilities everywhere and a system grown too complex for the tool to untangle, with no experienced human who knows where to look.
He points at the legal story of the week: both parties in a lawsuit citing AI-fabricated case law, verified by the bar, found to be invented, case dismissed and the lawyers sanctioned. His technical summary: the models are non-deterministic. Nine times out of ten the answer is sound, and the tenth is confidently fabricated. Building anything serious on that without experienced review is the whole risk, and the part of the iceberg vibe coders do not see is exactly the part a developer with a few hundred projects behind them is paid to see.
Asked why his relationship to AI is so untroubled, he offers a theory about his own path: he spent five months on formal training, not five years, so he holds his knowledge lightly. It costs him nothing to say that a given layer of what he learned can now be delegated to a machine, and to move his own effort up a level.
He connects it to the phrase teachers always used on him, learning to learn, and to why trigonometry was worth studying for someone who ended up in translation: the subject was never the point. His bet for the AI era is that pure expertise in one thing will matter less than the ability to have touched everything, because the person who has touched everything can hold a real conversation with the machine. He closes on the English proverb: jack of all trades, master of none, but better than a master of only one.
Why he stayed six years
The last thread of the episode is retention, and Sydney's answer has no slogan in it. The company grew from four people to around forty during his time. He gets along with everyone, which he credits partly to the same communication background as everything else, tourists, teammates, clients: exposure to enough publics teaches you that people are almost never acting in bad faith, they have simply hit a problem they had not seen.
The mechanics behind the culture are concrete. A retrospective every two weeks, where the team reviews what went well and what did not. His role at the start of each one is to restate the rule: the goal is to solve the problem at its source, never to assign blame, because a developer's entire day is solving problems, frequently ones they created themselves, and that has to be safe to say.
And a project lead who quotes Murphy's law often enough that it became method: whatever can go wrong will, so error handling covers the 0.1% case too, not because everything can be predicted, but because thinking about it is part of the job.
It is a fitting place for the episode to land. The path in was unconventional; the reasons for staying are the most conventional engineering culture there is, applied consistently for six years.
Transcription française
Transcription automatique du montage publié, avec correction de noms propres. Elle peut contenir des erreurs ; l’enregistrement fait référence pour une citation exacte.
Lire la transcription complète
Bonjour à tous, bienvenue dans Sequence, le podcast de DNA Solutions. Aujourd'hui, c'est un épisode qui est pas comme les autres déjà parce que c'est le premier et surtout que en général on accompagne les entreprises dans leur projet IA, tech et data analyse. En gros, on utilise la technologie pour comprendre les habitudes, les comportements, les gens. Là, on a décidé de faire plutôt
l'inverse, comprendre le monde de la tech avec ceux qui la vivent au quotidien et comprendre ce truc un peu tabou qu'on voit rarement sur LinkedIn, la réalité. [musique] Alors pour ce premier épisode, on a la chance de recevoir quelqu'un de très gentil avec un parcours qui est assez révélateur du monde de l'HIT et surtout de son tournant plutôt inattendu.
Bonjour Sydney De Clercq. Bonjour Sydney. Vous êtes product manager chez DNA Solutions. Je travaille aussi chez DNA Solutions donc est-ce qu'on peut se tutoyer déjà ? Oui bien sûr. [rires] Il paraît qu'il y a des gens qui ne savent pas encore ce que c'est qu'un product manager. Donc est-ce que tu pourrais les éclairer ? Product Manager, c'est quelqu'un qui s'assure de la bonne communication entre les équipes de développement
dans une compagnie tech. Les clients sont très concentré sur leur logique métier et les développeurs sont concentrés sur la décomposition technique en en feature. On a eu le cas où les clients séparaient les termes activité, session, événement. C'était trois termes bien individuels, bien séparés pour eux et nous on a tout regroupé en début et ça nous a valu
petit problème par la suite parce qu'on avait pas fait assez de séparation. Et du coup, c'est exactement mon travail en fait. Qu'est-ce qui fait qu'à un moment donné ces gens-là qui n'ont pas la même expertise arrivent à se comprendre ? Ça dépend de tout un chacun. Il y a certains clients qui sont plus techniques et à ce moment-là le le la communication se fait mieux. Et à l'inverse, des développeurs qui ont cette habitude de faire le le l'analyse
plus plus poussée de de tous les termes utilisés par les clients. Mais sinon, c'est mon rôle de m'assurer régulièrement tout au long d'un projet que on est aligné sur l'out de de ce qu'on essaie de produire. Est-ce que tu as fait une école d'informatique ? J'ai commencé des études de traduction et d'interprétation en anglais chinois. Rien à voir avec la tech. À la base, c'était des études de traduction et d'interprétation à listi
en anglais chinois. Anglais chinois ? Ouais. Angl chinois. Donc tu sais parler chinois un tout petit peu. J'ai j'ai vraiment pas on va pas te le demander maintenant mais je peux dire quelques phrases. Mais on pourrait pas faire ce podcast en chinois. Pas du tout. Bon déjà même en anglais ce serait difficile parce que je suis pas le meilleur non plus. En anglais ça [rires] commence c'est c'est très utile pour le métier de développeur de parler anglais.
Ça c'est c'est vital même. J'ai travaillé 5 ans comme conseiller touristique juste derrière à la Grand Place des Places Royale. Ça aussi c'était de la communication à des gens qui parlaient toutes sortes de langues. Tu as commencé par la traduction, maintenant tu es product manager donc tu as perdu du temps. Non je pense pas. Je pense que c'est une facilitation de la de la communication entre différentes personnes, différents groupes. La traduction, c'est entre gens
qui parlent pas la même langue et à la fin project manager. C'est entre le le client et le développeur qui même s'il parlent la même langue, n'utilise pas les mêmes termes. Le bagage que tu as développé par les études de traduction, est-ce que ça ça aide quand on veut coder ? C'est une facilité de de à travers les langages, à travers Oui, on peut dire ça. Le le code, ce n'est qu'un autre langage au final.
C'est une façon de de poser une logique et d'aider l'homme à parler à la machine quelque part. Oui, essentiellement. Et puis après, j'ai fait une formation intensive de dev 5 mois à la Wild Code School où on partait de rien, on était en reconversion professionnelle. Le but était de d'être employable à la fin, ce qui à l'époque ça recrutait des juniors
dans tous les sens. Donc j'ai eu la chance d'être recruté par Dira des les membres plus seigneurs. Ça ça recrutait plus à l'époque que maintenant. Oui, il y a il y a 6 ans maintenant, le le monde de la tech cherchait des développeurs à toutva parce qu'il y avait pas encore l'hiisation était en plein essort. Toute personne qui était un temps soit peu douée au
niveau au niveau tech, on la recrutait et on la forma au sein de la boîte. avec le recul, est-ce que tu aurais apprécié avoir un parcours plus académique dans l'apprentissage de de l'Haïti ou alors est-ce que tu t'es aperçu que la formation euh que tu as eu qui était intensive t'a déjà amené à un résultat pas encore le bon mais satisfaisant ? Ça m'a amené là où je voulais être, c'est-à-dire employable et je pense le
le travail du dev fait queon doit être en constant recyclage, en constante formation. Il y a des nouvelles technologies, des nouveaux outils qui sortent tout le temps. Donc je pense pas que j'aurais préféré faire des études de de 3 ou 5 ans universitaire. Mon mon but c'était pas de tout savoir sur le dev, c'était de de rentrer de rerentrer sur le marché pour me payer mon loyer. Enfin, je devais je devais trouver un
travail quoi. Donc 5 mois, c'était c'était le temps que je m'étais donné. Au-delà des connaissances sur le dev, qu'est-ce que tu retires de ce type de formation intensive ? C'était génial. Ça nous a donné une expérience sur le terrain. On a fait trois projets dont le dernier le plus complet était déjà avec des de vrais clients, même si c'était pour faire un projet, une esquise de projet mais que
elle a utilisé pour ensuite vendre et aller chercher des des investissements. Ça nous a fait un peu toucher à tout. Ça nous a fait découvrir le monde du dev intéressait. Après, on libre à nous de chercher plus de connaissances dessus. Je pense ce que l'université force à faire de par ces cinq études, on doit on doit apprendre l'histoire du code, les différents niveaux de de complexité et
d'abstraction, ce qu'on peut faire. Après, pendant qu'on travaille, on est employable au bout de 5 mois euh au lieu de 5 ans. Et bah, je pense que le marché du travail, c'est ce qu'il demandait à l'époque. En tout cas, en suivant cette logique là, qu'est-ce que tu conseillerais à quelqu'un qui en 2026 n'a plus cette opportunité d'accéder à un job de dev rapidement ? énormément de de des postes de junior ont été concédés à à l'IA parce que
c'est devenu hyper fort. Mais euh c'est possible de le faire en autodidacte, c'est plus facile de le faire en étant encadré. Mon conseil si ça vous plaît, allez-y, essayez. Il y a il y a plein de plein de plateformes, plein d'écoles pour être employable. Il faut être passionné. Il faut faut faire plein de projets sur le côté. C'est que ce soit des petits trucs, des afficher vos CD préférés, afficher une
librairie de vos de vos films préférés. Euh et ça ça marche encore en 2026 parce que j'ai l'impression que même pour les gens motivés qui ont un kitub avec plein de projets, c'est très difficile, non ? Pour le moment, le marché pour les junieurs oui est très difficile. Euh il faut il faut continuer, il faut se donner. C'est je pense pour plein de marchés, même ceux qui sont saturés, si quelqu'un est passionné, il finira par trouver. Hm
hm. Des une des méthodes que tu utilisais le plus, c'est la méthode agile. Ouais. Alors l'agilité, j'ai je vois plus ou moins ce que c'est. La méthode agile, j'ai des lacunes. Est-ce que tu peux m'expliquer ? La méthode agile, c'est une méthode qui est apparue il y a 25 ans dans le le manifeste agile qui a été cré en en 2001, il me semble. Ouais. Et c'est une façon de travailler en en itération
selon le projet. Ça peut être toutes les de semaines, 3 semaines, 4 semaines où on a des rendez-vous récurrents avec l'équipe technique et les clients pour s'aligner sur les besoins plutôt qu'il nous donne toute la description du projet et qu'on se revoit 3 mois, 6 mois plus tard et qu'on se rende compte que bah en fait il y avait des points qui étaient pas du tout raccord. Tous les mois ou toutes les deux semaines, on livre une itération fonctionnelle au
client. Voilà, regardez cette page-ci ou cette partie-ci, est-ce qu'elle vous convient sur base de ce qu'on avait déjà discuté ? Et puis on corrige le tir. Ça permet aussi au sein de l'équipe de développement de s'améliorer, d'apprendre de nos erreurs, qu'est-ce qu'on a bien fait, qu'est-ce qu'on a mal fait et bah en construisant toutes les semaines jusqu'à la fin du projet de de tirer de l'expérience aussi de de de nos
leçons, de nos erreurs. Et qu'est-ce qui se passerait si la méthode agile n'avait jamais existé ? On travaillerait encore en waterfall, ça s'appelle en cascade où bah les clients nous donnent leur des idées rata et 6 mois, un an plus tard, on livre les clients étaient rarement satisfaits où il y avait toujours des des Mais pourquoi pourtant tu leur as livré ce qu'il attendaient si ça règle le problème, oui mais
parfois ça le règle pas comme lui s'attendait à ce que ça le règle. On revient au problème initial où les les clients expriment leurs besoins avec un langage métier qui pour eux est logique et clair entre toi ce que tu ce que tu t'imagines et ce que la personne s'imagine, il y a pas toujours des mêmes choses quand deux personnes lisent un livre. Il s'imagine pas la même chose. Des fois nous on doit lire entre les
lignes pour pour proposer une meilleure solution. Des fois on peut régler deux problèmes d'un coup règle sans forcément rentrer dans les détails techniques. Mais comment on règle deux problèmes d'un coup ? Ou ou ou plutôt comment on fait pour livrer au client une meilleure solution que celle qu'il a demandé ? On essaie de comprendre la globalité de de leur demande. Peut-être qu'ils essayent de résoudre leur problème mais qu'ils en ont d'autres. On nous a demandé de faire
pour euh des auto-écoles un planning. Leur planning était fait sur un vieux programme euh Windows qui datait d'il y a 30 ans, je pense. Ils avaient des plein d'informations en très petit sur un petit écran, mais pour eux toutes les informations importantes étaient là. le la couleur du texte et les abréviations. Nous, on leur a proposé une nouvelle vue plus flexible avec toutes ces
informations mais en plus ou là la solution qui n'attendait pas c'était que ce soit customisable par type d'activité. Donc que chaque activité il puisse dire ça c'est les informations importantes qu'on veut voir pour ce type d'activité. Ils étaient enchantés quand on leur a montré que ils pouvaient activer ou désactiver chacun de ses champs. Donc parfois ils ont du mal à formuler la meilleure demande parce que ils n'ont
pas le tout le bagage technique que que toi ou que ils sont concentrés sur un problème majeur à résoudre mais il y a plein de petites qualités de vie qui pourraient être ajouté autour de ça. [musique] Il paraît que ton truc c'est les jeux vidéos mais que toi tu as été joueur semi pro. Est-ce que tu peux nous parler de ce cette histoire J'étais joueur semi
pro sur Overwatch il y a 7 ans maintenant. Ouais. Overwatch pour pour te faire une explication sommaire. Chaque personnage a ses capacités, ses ultimes, ses pouvoirs propres. Et euh moi je jouais tank et j'avais aussi le rôle de showcer, de chef d'équipe, gérer les interviews postmch, gérer les les attitudes de chacun.
pendant la partie, il y a des il y a de l'animosité, il y a il y a de la pression, les gens scrivent dessus parce qu'on perd, parce qu'on fait pas ce qu'on a ce qu'on ce qu'on a dit qu' qu'on faisait, parce que l'exécution n'est pas toujours parfaite. Enfin, c'est c'est quoi souvent les questions qui reviennent les les problèmes qui reviennent tout le temps sur la c'est la frustration, c'est comment comment c'est
possible ? Moi, j'ai fait tout ce que je pouvais pour gagner, je me suis donné à fond. C'est sûrement les autres qui ont déconné. Il faut analyser les vidéos, les replay, voir OK ce que chacun aurait pu faire individuellement et en quoi c'est difficile d'être chef sur Overwatch. ça revient à un problème de communication. Euh c'est toujours plus la communication peut être claire et rapide, surtout dans des jeux où où s'il faut prendre des décisions en en
quelques secondes, si la décision est mauvaise ou si les gens paniquent et et réagissent mal, tout ça peut créer de la frustration. Et bah c'est le but c'était de s'entraîner et de devenir meilleur à ça. Ouais. Quel lien tu peux faire entre Overwatch et ton métier actuel dans l'HiT ? Surtout les points de de communication avec le reste de l'équipe, c'est de la gestion de d'information en temps réel.
Non, je manque chef de projet, c'est peut-être pas des décisions à la seconde près. Quoi ? C'est ça demande plus de rapidité euh Overwatch. Oui, c'est en quelques secondes, il faut savoir qu'est-ce qu'on va faire dans le le combat qui va arriver euh 5 à 10 secondes après. Overwatch, c'est une super école pour être chef de projet. Oui, on pourrait dire ça. Overwatch, c'est effectivement une super école pour être chef de projet. connaissance du projet, de tous les tenants et les
aboutissants, des demandes clients, des contraintes techniques, de l'objectif de du des différents problèmes et solutions, euh faire une road map de tout ce qu'on va devoir livrer, s'il y a des parties qui s'entreconnectent, des intégration externes, enfin voilà. Bref, à la fois la communication entre les gens et la communication entre les types de technologie. Il paraît aussi que enfin, il paraît, je le sais très bien vu qu'on a préparé le l'entretien, mais
est-ce que tu peux un peu nous parler des différents projets que tu as mené un peu sur le côté ? Euh j'ai fait plein de petits projets euh sur le côté pour apprendre techniquement. Parmi les plus gros, euh il y avait une une application qui s'appelait Apply Future. C'était un site web qui centralisait les inscriptions pour euh tous les étudiants étrangers dans des
universités euh essentiellement en France. C'était destiné à un public chinois mais ça don à terme l'idée c'était de d'ouvrir ça à n'importe qui. Chaque haute école ou université, les étudiants doivent remplir tout un formulaire avec leurs informations, dates de naissance et cetera, les résultats du test TOï, leur leur lettre de motivation et cetera. Le but c'était de centraliser. Il faisaient ça une fois sur la plateforme et puis juste appuyer
sur le bouton pour s'inscrire. Le Covid a brutalement arrêté le projet mais ça pourrait être relancé. Je pense qu'il y a il y a toujours une demande pour ça. Un des autres projets, c'est le site web de ma copine qui fait organisatrice de voyage. Ça m'a appris beaucoup de choses pour tout ce qui est le côté SEO, aller chercher des clients, se concentrer sur le produit. Qu'est-ce qui va apporter le plus de valeur ajoutée ?
Et tu avais pas un projet avec des cartes Pokémon aussi ? [rires] J'ai fait un petit un petit système mais que j'ai pas déployé juste pour pour arranger des cartes Pokémon par couleur pour que ça donne un truc un peu joli si on le met sous cadre. Comment est-ce que tu t'y prends à chaque fois que tu démarres un projet ? Parce que je suppose que en multiplier les projets, ça demande quand même de savoir aller vite.
Oui, pour le moment avec les I permet d'aller encore plus vite. Moi, j'utilise Cloud pour le moment. Il suffit de d'expliquer en français basique la demande. Évidemment, si on peut mettre des détails techniques, des détails de développeur, ça c'est un avantage parce que ça va aider l'IA à structurer le projet. Et c'est quoi l'avantage de l'IA ? Du coup, ça fait tout le code, toute l'exécution beaucoup plus rapidement qu'un humain pourra jamais le faire. Même au-delà du code, par exemple, tu
parlais du référencement, comment est-ce que l'IA t'aide ? C'est un expert qu'on a ses côtés constamment sur tous les sujets et c'est ça qui est incroyable. Pour absolument chaque étape d'un projet, on peut utiliser LIA pour soit pour faciliter la démarche humaine qui doit être faite, soit juste pour outrepasser cette démarche humaine et que l'IA la fasse à la place de l'humain. Donc tu confieris tout à l'a Non, il y a il y a des décisions qui
peuvent pas être confiées à l'IA euh que ce soit des des décisions technique comme on a pu voir sur Twitter des des IA qui suppriment toute la base de données parce que l'humain a pas lu et que ouais [rires] il a accepté ou donner les autorisations à lié pour pour faire ce genre de chos des décisions techniques finales de de l'architecture ou ou la base d'un projet la réflexion initielle ça je laisserai à
l'humain quitte à la confronter par la suite à l'analyse de l'IA et à construire quelque chose sur base de cette de cet échange, même si Lia de nouveau peut aider à la réflexion, c'est pas Lia qui doit prendre cette décision. Quel est pour toi le rôle de la capacité à prendre les décisions à l'heure de l'IA ? Pour tout ce qui est exécutif, la meilleure façon de résoudre un problème. Je pense qu'on peut faire confiance à
Lia. Si si on veut de la rapidité, peut dire "Al tu as tous les droits pour prendre les meilleures décisions techniques, je te fais confiance. On pourrait s'arrêter étape par étape et puis à chaque fois lire toutes les quelques propositions de LIA et choisir manuellement. Mais si on décide de faire confiance à l' il y a pas de souci de de lui confier si c'est une question de rapidité. Moi, je ne suis pas trop dans le monde
de de l'IT. Donc je mets à chaque fois à la place d'un développeur qui a étudié un langage pendant des années, qui a développé une expérience technique. On a souvent l'exemple de gens qui disent là, j'ai codé sans sans coder, j'ai sorti un produit, c'est c'est les vibe coder, on appelle ça. Pour toi, c'est quoi le principal danger du vibe coding ? c'est que on respecte on respecte rien, c'est le résultat qui compte et tant que ça marche, ça marche.
Et à partir du moment où ça pète, siia n'arrive pas à résoudre le problème sans quelqu'un d'expérimenter, il se rendent compte qu'en fait il y a plein de vulnérabilité, que il y a plein de choses qui cassent, que c'est impossible à maintenir parce que ça a tellement grandi en complexité que Li n'arrive plus à résoudre le problème. Imaginons que je travaille pour un docteur ou un cabinet d'avocat et que je fais mon application Vibe coding, quels sont les risques ?
Pour prendre l'exemple des avocats et de de tout le milieu légal, euh encore la semaine dernière, j'ai vu un article euh où les deux parties dans un dans un procès avaient inventé des cas en utilisant l'IA et donc l'IA a sorti des des exemples complètement fabriqués qui du coup ont été vérifiés et étaient introuvables par le barreau et le juge a classé
l'affaire. Euh je sais pas si elle va avoir le droit à un rejugement ou mais euh faut faut y a peut-être une A qui va décider de ça. Voilà, c'est ça. Il y aura il y aura toute une enfin tout un une enquête. Il me semble que les avocats ont été ont été pénalisés aussi. Enfin, c'est la c'est non déterministe. Donc 9 fois sur 10, on va peut-être avoir un résultat probant et la 10e fois, ça va être
complètement inventé. C'est très difficile d'avoir quelque chose de régulier avec L. On n pas forcément conscience des limites quand quand on vibe code. On veut on veut une solution rapide et efficace mais mais toute la partie émergé de l'iceberg, c'est c'est à ça que les les vibe coder ne pensent pas. Et c'est cette expérience qu'à un développeur qui a travaillé sans lia qui a déjà fait des des dizaines voire des
centaines de projets va pouvoir apporter "Ah mais est-ce que tu as pensé à cette partie-là de faire la conception initiale d'un projet et de la solution par soi-même avant de l'adresser à Lia ? parce que alors Lia va pouvoir d'une part challenger mais aussi se baser sur tout ce qui a déjà été envisagé. [musique] Imaginons que on soit pas tous les deux
employés chez DNA Solutions. Imaginons, même si ce serait dommage parce que on travaille pour de très gentils patrons et dans un cadre bienveillant, humain et en tout cas dans ton cas, ça fait quand même 6 ans que tu es là. Euh qu'est-ce qui te fait rester ? On est une quarantaine maintenant j'ai commencé, on était j'étais le 3e employé il me semble ou non 4e employé chacun a son caractère mais mais euh
il y a pas l'effet euh que tu te lèves le matin oh non pas lui. Non je m'entends bien avec tout le monde vraiment ça c'est c'est cool. Mais c'est peut-être aussi ça fait partie du travail de communication. L'expérience avec des publics étrangers dans le milieu du tourisme le fait d'avoir un parcours dans le fil conducteur c'est la communication ça t'aide dans le monde de l'entreprise avec tes collègues d'être confronté à plein de publics différents, que ce soit les touristes
dans les jeux vidéos. Enfin voilà tout tous ces publics différents m'ont aidé à faire avec à comprendre que bah que chacun a sa personnalité, qu'en général les gens sont pas de mauvaise foi, qui veulent faire avancer le problème, que quand il y a un problème bah ils avaient pas pensé ou ils avaient pas vu. Enfin les gens ont assez peu souvent de mauvaises intentions et dans le monde du travail c'est quand même assez rare que sur 40
employés tu t'entendes bien avec tout le monde. Je travaille pas aussi étroitement avec tous mes collègues. Donc depuis 6 ans, j'ai pas mal tourné dans les dans les différents groupes et dans les différents projets. Est-ce que il y a il y a des choses qui sont mis en place pour un des une des réunions chez nous, c'est toutes les deux semaines qui s'appelle la rétrospective où on fait le point sur tout ce qui s'est bien et mal passé et
on apprend ses erreurs. Donc c'est toujours tourner vers l'amélioration de l'équipe et de façon générale le développeur passent son temps à régler des problèmes. Des fois des problèmes qu'ils ont créé eux-mêmes, mais ça c'est pas grave. Qu'on veut on veut constamment s'améliorer, on veut résoudre le problème et pas blâmer les gens. Ça fait partie de mon travail de le rappeler en début de chaque rétrospective que le but c'est répondre et solutionner le problème de tacler
vraiment la la source de de ce qu'on a eu et pas de de juste accuser. On a tendance à se préparer au pire mais à espérer le meilleur outcome. Notre chef du gros projet sur lequel on est pour le moment adore adore ramener la loi de Murphy en disant que s'il y a quelque chose qui doit aller mal, ça ira mal. Donc il faut se préparer à cette éventualité des gestions d'erreurs. C'est des tests récurrents. C'est une
c'est une façon de travailler, d'aller voir les cas d'erreur même ultra poussé. Si c'est 0,1 % de chance que ça arrive, faut quand même qu'on le gère. On a une manière saine de ne de ne pas forcément chercher à éviter l'erreur à tout prix mais à l'anticiper parce que il y a un réalisme. Ce qu'on essaie de faire, c'est impossible de tout prévoir et de tout régler à l'avance mais ça fait partie de notre travail de d'y penser. Pour
revenir justement à LIA, on sent que tu as un rapport qui est quand même assez détendu à LIA. Est-ce que dans ton parcours, il y a quelque chose qui a fait que tu as ce rapport à l'intelligence artificielle ? Peut-être parce que j'ai eu cette formation intense et que j'ai pas passé 5 ans de ma vie à galérer. Et moi, j'ai n'ai passé entre guillemets que 5 mois mais j'ai continué à me former. Mais c'est peut-être plus facile pour moi de
dire bah OK, cette formation, peut-être que Lia aurait pu m'apprendre en en une semaine tout ce que j'ai appris et que que j'ai plus facile à passer au nouveau et à me recycler et à dire bah OK, ces connaissances là maintenant, je peux les mettre de côté, je peux les confier à lire. Je sais pas si c'est le lié à mon parcours, c'est une philosophie de de vie. J'aime bien constamment apprendre, challenger ce que je sais déjà, que ce
soit dans un dans un débat avec des amis, dans une discussion, j'ai tendance à faire l'avocat du diable, avoir plusieurs approches, ça aide à la compréhension globale d'un sujet. Dans ton parcours, j'ai l'impression que tu as développé une grande facilité d'apprendre à apprendre. Fait rire que tu dises apprendre à apprendre parce que c'est une phrase qu'on m'a répété à l'école. À quoi ça sert les maths, quoi j'apprends la trigonométrie, c'est une façon d'apprendre à apprendre. tu auras jamais
besoin de math si tu fais de l'histoire ou de la traduction ou peut-être que 10 ans plus tard, tu feras chef de projet et en fait bah si tu auras peut-être besoin d'un peu de math et et même après dans ma formation de dev, c'est une façon d'apprendre à apprendre. Peut-être qu'on aura plus cette nécessité d'être des experts dans quoi que ce soit mais que l'avantage d'être polyvalent, d'avoir un peu touché à tout, ça permettra de d'avoir des discussions
avec Lia et de s'adapter beaucoup plus facilement que des gens qui n'ont fait qu'une seule chose toute leur vie. Il y a il y a une expression en anglais qui dit Jack of all trades, master of none but better than master of only one. Donc il vaut mieux avoir plusieurs cordes à son arc que d'être expert dans une seule chose. Je pense qu'on a tout dit. Merci beaucoup Sydney Declerc. Merci à vous. On pe tutoyer.
Merci à toi. Merci à toi Théo. Faut pas oublier qu'on est collègue. Voilà, on arrive déjà à la fin de ce premier épisode de Sequence. Si ça vous a plu, vous pouvez nous retrouver sur Spotify, Apple Podcast, 10h et YouTube. Vous pouvez aussi nous suivre sur Instagram, TikTok, on verra. Mais en tout cas, LinkedIn, ça c'est sûr. Évidemment, un grand merci à DNA Solutions pour la confiance et on se retrouve très vite. [musique]
Related services: Custom Software Development, IT Consulting
