Your Data Isn’t Dirty. It’s Unstructured. That’s the Point. Vos données ne sont pas sales. Elles sont non structurées. C'est le but.

By Suzanne Chartol and Adeline Chartol · Par Suzanne Chartol and Adeline Chartol · 5 June 2026

A Nextgov essay recently warned that federal agencies are rushing into AI without cleaning house first—that years of governance debt, broken permissions, and abandoned knowledge management practices are setting up a security and quality crisis. The piece raised a legitimate concern about SharePoint access controls and sensitive files surfacing where they shouldn’t. But it also reflected something we hear in nearly every conversation with government customers, an assumption so widespread it has become a kind of conventional wisdom: that data needs to be cleaned up, organized, and governed before AI can do anything useful. We think that framing gets it exactly backwards, and a moment from a recent training workshop is a good illustration of why.

Suzanne: We were running a training workshop for a group of government users, teaching them how to use our AI by working with their actual data. One of the participants had his spreadsheet open on his laptop so he could fact-check the AI’s answers in real time—he wanted to see how reliable it was. He’d suggest a question, we’d put it to the AI, and he’d check the answer against what he knew. At one point he suggested a question and then immediately regretted it. The fields in his spreadsheet weren’t structured data in any conventional sense—they were free text, notes and descriptions typed into cells, the kind of information that doesn’t lend itself to formulas or pivot tables. He said he shouldn’t have asked that, because even his own pivot table couldn’t have handled it—the data wasn’t clean enough. But the AI did handle it. It read the text inside those fields, parsed the meaning, and then aggregated and analyzed across the full dataset. He said nothing he’d tried before could do that with his data.

That reaction captures something important about where the federal AI conversation has gone wrong. When government leaders say their data is messy, they almost never mean it’s wrong. They mean it doesn’t look the way traditional analytics expects it to look. The information they rely on lives in PowerPoint decks that hold an entire program’s status history, in PDFs that serve as the authoritative source documents, in email threads where decisions were actually made, in spreadsheets where someone typed notes into a column instead of using a dropdown. It lives in SharePoint sites and shared drives and legacy systems that don’t talk to each other. None of this is dirty data. It’s the natural state of how organizations create and store information, and it’s been accumulating for decades. If you’re waiting for it to become clean and structured before you deploy AI, you are waiting for a day that is never going to arrive.

The irony is that unstructured data is precisely what modern AI was designed to handle. The entire value proposition of large language models and retrieval-augmented generation is that they can read, interpret, and reason over information that no traditional system could parse—the text inside a spreadsheet cell, the narrative buried in a PDF appendix, the context scattered across a hundred slides. If the data were already clean and sitting in a relational database, you wouldn’t need AI; you’d just need a decent query tool.

That said, you can’t just point a language model at a pile of PowerPoints and expect answers you’d bet your program on. What the man in the workshop was reacting to wasn’t magic—it was tooling. At CORAS, we pair a natural language processing engine with large language models that use code to work with unstructured data programmatically. The NLP layer parses and structures what’s inside those documents and spreadsheets; the LLM reasons over it through code execution rather than just generating text. That combination is what produces repeatable results—not a model taking its best guess, but a pipeline that can reliably extract, cross-reference, and analyze information the same way every time. The other AI tools he’d tried couldn’t handle it because they were pure language models trying to do something that requires engineering underneath. The difference isn’t the model; it’s the infrastructure around it.

But even the right tooling doesn’t help much if you’re trying to solve the whole problem at once. The mistake I see most often with government customers isn’t a lack of data readiness—it’s a lack of focus. Someone decides the organization needs AI, and the next step is a multi-year data governance initiative to get everything in order before anyone is allowed to use it. Meanwhile, the people doing the actual work—the analysts, the program managers, the logistics specialists—are still manually digging through hundreds of pages of documentation to answer a question that AI could handle in seconds. The governance initiative becomes the reason nobody gets help.

What works, in our experience, is the opposite: start with a single use case that matters to real people, and deliver a win fast enough that the value is undeniable. We think of it as crawl, walk, run. Crawl means finding a specific pain point—something concrete that someone is struggling with today—and solving it with a small group of people who are already willing to try. The goal is to produce a result in days, not months: an answer that used to require hours of digging through PDFs and slide decks, a status check that meant pulling from five different systems, a summary that nobody had time to write. Walk means expanding outward once those early users are bought in, adding structure around the quick wins, connecting additional data sources, letting the people who saw value first become the advocates for everyone else. Run means you’ve earned the right to talk about predictive analytics and executive dashboards and mission-level intelligence—not because you started there, but because you built a foundation of demonstrated value that makes the bigger conversation possible.

Adeline: The European version of the “we’re not ready” argument follows a similar pattern, though it tends to be even more procedurally entrenched. At the European Parliament, I’ve watched the readiness conversation consume months of institutional energy: leadership acknowledges AI’s potential, a working group is convened, and the discussion migrates from “can we use this tool” to “who owns the data,” “how is it classified,” “what’s the retention policy.” By the time those questions are resolved—if they ever are—the original use case has either lost its urgency or its champion has moved on to a new posting.

I’ve observed a more instructive model at the ESM. Rather than treating governance as a prerequisite for adoption, the ESM has moved on both tracks simultaneously, piloting tools and building institutional knowledge while defining strategy and guardrails in parallel. That approach reflects a more realistic understanding of how readiness actually works.

The irony is that the EU arguably has a head start on the governance side. GDPR forced European institutions to think seriously about data classification, purpose limitation, and access controls years before most American agencies started that conversation. But all that governance maturity hasn’t uniformly translated into faster AI adoption—if anything, it has raised the threshold for what “ready” means in many quarters. A persistent misconception remains: that data must be structured, clean, and perfectly catalogued before AI can deliver value. In practice, some of the most useful AI applications work precisely on the messy, unstructured information that institutions already have in abundance. The lesson is that governance and adoption have to move in parallel rather than in sequence—because the governance work never reaches a natural stopping point, and waiting for it to do so is itself a choice with real costs.

Suzanne: There’s a real cost to the delay, and it compounds. In US agencies, headcount has been cut and the work hasn’t gone away, and the people who remain don’t have the luxury of waiting for a readiness initiative to conclude before they get help. They need tools that work with the data as it exists—in the PowerPoints and PDFs and text-filled spreadsheets where it already lives. The “clean your data first” framing sounds like prudence, but in practice it becomes permission to defer indefinitely, and the data doesn’t improve while you deliberate. It gets worse, because the unstructured pile grows with every report filed, every deck updated, every departing colleague who takes institutional knowledge with them.

Fix your permissions—that’s a legitimate security concern that deserves attention whether or not AI is in the picture. But don’t confuse access governance with data readiness, and don’t let the pursuit of a perfectly organized information environment keep you from helping the people who need help now. Find a use case that matters, start with people who are ready, deliver something they can point to, and build from there. The man with the spreadsheet was sure his data was too messy. It wasn’t. It was just waiting for the right tools to make sense of it.

Suzanne writes from the US. Adeline writes from the EU. Neither waited for clean data to start.

Un article de Nextgov mettait récemment en garde contre le fait que les agences fédérales se précipitent sur l'IA sans avoir préalablement fait le ménage dans leurs systèmes. Des années de dettes de gouvernance, des permissions défaillantes et des pratiques de gestion des connaissances abandonnées sont en train de créer une crise de sécurité et de qualité. L'article soulevait une préoccupation légitime concernant les contrôles d'accès à SharePoint et la diffusion de fichiers sensibles là où ils ne devraient pas. Mais il reflétait aussi une idée reçue que nous entendons presque systématiquement avec nos clients du secteur public : les données doivent être nettoyées, organisées et gouvernées avant que l'IA puisse être utile. Nous pensons que cette vision est totalement erronée, et un exemple tiré d'un récent atelier de formation l'illustre bien.

Suzanne : Nous animions un atelier de formation pour un groupe d'utilisateurs gouvernementaux, afin de leur apprendre à utiliser notre IA avec leurs propres données. Un des participants avait son tableur ouvert sur son ordinateur portable pour vérifier en temps réel les réponses de l'IA et tester sa fiabilité. Il suggérait une question, nous la soumettions à l'IA, et il comparait la réponse à ses connaissances. À un moment donné, il a posé une question qu'il a immédiatement regrettée. Les champs de son tableur ne contenaient aucune donnée structurée au sens conventionnel du terme : il s'agissait de texte libre, de notes et de descriptions saisies dans les cellules, un type d'information qui ne se prête pas aux formules ni aux tableaux croisés dynamiques. Il a admis qu'il n'aurait pas dû poser cette question, car même son propre tableau croisé dynamique n'aurait pas pu la traiter : les données n'étaient pas suffisamment propres. Mais l'IA, elle, l'a fait. Elle a lu le texte dans ces champs, en a interprété le sens, puis a agrégé et analysé l'ensemble des données. Il a affirmé que rien de ce qu'il avait essayé auparavant n'avait permis d'obtenir un tel résultat avec ses données.

Cette réaction met en lumière un point crucial du débat fédéral sur l'IA. Lorsque les dirigeants affirment que leurs données sont désordonnées, ils ne veulent presque jamais dire qu'elles sont erronées. Ils veulent simplement dire qu'elles ne correspondent pas aux attentes des analystes traditionnels. Les informations sur lesquelles ils s'appuient se trouvent dans des présentations PowerPoint contenant l'historique complet d'un programme, dans des PDF faisant office de documents sources officiels, dans des échanges de courriels où les décisions ont été prises, dans des tableurs où des notes ont été saisies manuellement au lieu d'utiliser des menus déroulants. Elles sont stockées sur des sites SharePoint, des lecteurs partagés et des systèmes hérités qui ne communiquent pas entre eux. Il ne s'agit pas de données « sales ». C'est l'état naturel des organisations quant à la création et au stockage de l'information, et ces données s'accumulent depuis des décennies. Attendre qu'elles soient propres et structurées avant de déployer l'IA, c'est attendre un jour qui n'arrivera jamais.

L'ironie, c'est que les données non structurées sont précisément ce pour quoi l'IA moderne a été conçue. Tout l'intérêt des grands modèles de langage et de la génération augmentée par la recherche réside dans leur capacité à lire, interpréter et raisonner sur des informations qu'aucun système traditionnel ne pourrait analyser : le texte d'une cellule de tableur, le récit enfoui dans une annexe PDF, le contexte dispersé sur une centaine de diapositives. Si les données étaient déjà propres et stockées dans une base de données relationnelle, l'IA serait superflue ; un simple outil de requêtes performant suffirait.

Cela dit, on ne peut pas simplement pointer un modèle de langage vers une pile de présentations PowerPoint et s'attendre à des réponses fiables. Ce à quoi réagissait l'homme de l'atelier n'était pas de la magie, mais des outils. Chez CORAS, nous associons un moteur de traitement automatique du langage naturel (TALN) à de vastes modèles de langage qui utilisent du code pour traiter des données non structurées de manière programmatique. La couche TALN analyse et structure le contenu de ces documents et feuilles de calcul ; le modèle de langage effectue un raisonnement sur ces données par l'exécution de code plutôt que par la simple génération de texte. C'est cette combinaison qui produit des résultats reproductibles : non pas un modèle qui fait de son mieux, mais un pipeline capable d'extraire, de recouper et d'analyser les informations de manière fiable et constante. Les autres outils d'IA qu'il avait essayés étaient incapables de gérer cela, car il s'agissait de simples modèles de langage tentant de réaliser une tâche qui exige une ingénierie sous-jacente. La différence ne réside pas dans le modèle, mais dans l'infrastructure qui le sous-tend.

Mais même les outils adéquats ne suffisent pas si l'on tente de résoudre l'ensemble du problème d'un seul coup. L'erreur que je constate le plus souvent chez les clients du secteur public n'est pas un manque de données prêtes, mais un manque de concentration. Quelqu'un décide que l'organisation a besoin d'IA, et l'étape suivante consiste en une initiative de gouvernance des données pluriannuelle pour tout mettre en ordre avant que quiconque puisse l'utiliser. Pendant ce temps, les personnes qui effectuent le travail de terrain — les analystes, les chefs de projet, les spécialistes en logistique — continuent de parcourir manuellement des centaines de pages de documentation pour répondre à une question que l'IA pourrait traiter en quelques secondes. L'initiative de gouvernance devient alors le prétexte pour ne recevoir aucune aide.

D'après notre expérience, ce qui fonctionne, c'est l'inverse : partir d'un cas d'usage unique et pertinent pour de vraies personnes, et obtenir rapidement un résultat concret pour que la valeur soit indéniable. Nous l'envisageons comme une progression en trois étapes : ramper, marcher, courir. « Ramper » signifie identifier un problème précis – un souci concret auquel quelqu'un est confronté aujourd'hui – et le résoudre avec une petite équipe déjà motivée. L'objectif est d'obtenir un résultat en quelques jours, et non en plusieurs mois : une solution qui nécessitait auparavant des heures de recherche dans des PDF et des présentations, un point d'étape impliquant la consultation de cinq systèmes différents, et un résumé que personne n'avait le temps de rédiger. « Marcher » signifie étendre la portée une fois les premiers utilisateurs convaincus, structurer les succès rapides, connecter des sources de données supplémentaires et faire en sorte que ceux qui ont perçu la valeur en premier deviennent les ambassadeurs de la solution. « Courir » signifie avoir acquis la légitimité de parler d'analyse prédictive, de tableaux de bord de direction et d'intelligence stratégique – non pas parce que vous avez commencé par là, mais parce que vous avez bâti une base de valeur démontrée qui ouvre la voie à des discussions plus larges.

Adeline : La version européenne de l’argument du « nous ne sommes pas prêts » suit un schéma similaire, bien qu’elle soit souvent encore plus ancrée dans les procédures. Au Parlement européen, j’ai vu le débat sur la préparation engloutir des mois d’énergie institutionnelle : la direction reconnaît le potentiel de l’IA, un groupe de travail est mis en place, et la discussion passe de « pouvons-nous utiliser cet outil ? » à « à qui appartiennent les données ? », « comment sont-elles classées ? », « quelle est la politique de conservation ? ». Lorsque ces questions sont enfin résolues – si elles le sont un jour –, le cas d’usage initial a soit perdu de son urgence, soit son défenseur a changé de poste.

J'ai observé un modèle plus instructif au sein du MES. Plutôt que de considérer la gouvernance comme une condition préalable à l'adoption, le MES a progressé simultanément sur les deux fronts : expérimentation d'outils et développement des connaissances institutionnelles, tout en définissant en parallèle la stratégie et les garde-fous. Cette approche témoigne d'une compréhension plus réaliste du fonctionnement concret du processus de préparation.

L'ironie est que l'UE a sans doute une longueur d'avance en matière de gouvernance. Le RGPD a contraint les institutions européennes à réfléchir sérieusement à la classification des données, à la limitation des finalités et aux contrôles d'accès des années avant que la plupart des agences américaines n'entament cette réflexion. Cependant, cette maturité en matière de gouvernance ne s'est pas traduite de manière uniforme par une adoption plus rapide de l'IA ; au contraire, elle a rehaussé le seuil de ce que signifie être « prêt » dans de nombreux milieux. Une idée fausse persiste : les données doivent être structurées, propres et parfaitement cataloguées avant que l'IA puisse apporter de la valeur. En pratique, certaines des applications d'IA les plus utiles fonctionnent précisément avec les informations désordonnées et non structurées dont les institutions disposent déjà en abondance. La leçon à retenir est que la gouvernance et l'adoption doivent progresser en parallèle et non successivement, car le travail de gouvernance n'atteint jamais de point d'arrêt naturel, et attendre qu'il en soit un représente un choix coûteux.

Suzanne : Ce retard a un coût réel et croissant. Dans les agences américaines, les effectifs ont été réduits, mais la charge de travail demeure. Le personnel restant n’a pas le luxe d’attendre la fin d’une initiative de préparation pour obtenir de l’aide. Il leur faut des outils capables d’exploiter les données telles qu’elles existent déjà : les présentations PowerPoint, les PDF et les tableurs remplis de texte. L’idée de « nettoyer ses données d’abord » semble judicieuse, mais en pratique, elle revient à autoriser le report indéfini des actions, et les données ne s’améliorent pas pendant ce temps. Pire encore, la pile de données non structurées grossit à chaque rapport déposé, chaque présentation mise à jour, chaque collègue qui quitte l’entreprise en emportant avec lui le savoir-faire de l’institution.

Corrigez vos permissions : c’est un problème de sécurité légitime qui mérite d’être pris en compte, que l’IA soit impliquée ou non. Mais ne confondez pas gouvernance des accès et préparation des données, et ne laissez pas la recherche d’un environnement informationnel parfaitement organisé vous empêcher d’aider ceux qui en ont besoin immédiatement. Trouvez un cas d’usage pertinent, commencez par les personnes prêtes, fournissez-leur un exemple concret et développez votre solution à partir de là. L’homme au tableur était persuadé que ses données étaient trop désordonnées. Elles ne l’étaient pas. Elles attendaient simplement les bons outils pour être exploitables.

Suzanne écrit des États-Unis. Adeline écrit de l'Union européenne. Aucune des deux n'a attendu de disposer de données fiables pour commencer.

Also published on Substack. Subscribe to get new dispatches by email. Également publié sur Substack. Abonnez-vous pour recevoir les nouvelles dépêches par e-mail.

Your Data Isn’t Dirty. It’s Unstructured. That’s the Point. Vos données ne sont pas sales. Elles sont non structurées. C'est le but.

Subscribe S'abonner